none
遇到一個很奇怪的問題,請大家幫忙下 RRS feed

  • 问题




  • 我這邊遇到一個很奇怪的問題,均使用完全備份加日志備份文件恢復的數據庫到兩臺機器上,只是兩邊機器的配置不一樣。

    機器1是單顆4核CPU  E5420(2.49GHZ),機器2是4顆4核CPU E7440(2.39GHZ)。另外就是內存差異比較大(16G對32G)。

    由于是使用生產庫上的備份文件恢復到這兩臺機器上的,所以這兩臺機器上的數據庫是一樣的。但是現在遇到一個問題,

    在機器1和2上的相同的執行sql的執行計劃不一樣,而且最令人吃驚的是 在機器1上的運行速度(4S)明顯快于機器2的速度(28S)。

    請問下,造成這個的原因大致是什么?為什么差異會這么大,并且配置好的速度還慢?
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月21日 10:36

答案

全部回复



  • it is sql server 2000 here
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月21日 10:49
  • 如果数据库结构一样,sql语句一样,那么就是物理环境问题了

    不过你提到 查询计划不一样,你可以一一对照 ,到底哪里不一样了,比如:哪里使用索引 哪里没使用,这样应该能够发现点什么线索

    sql的版本(补丁)是否一致,系统环境是否一致,sql内存使用情况等等都核对一下

    问题差不多就能找到了吧。
    family as water
    2009年9月21日 11:50
  • Also check wait type of the process, maybe caused by parallelism.
    2009年9月21日 14:04
  • 我已經檢查了所有的配置,因為是使用備份文件恢復的,所以數據庫是一致的。 最主要的差別在于硬件環境。
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月22日 0:04


  • 聽說硬件環境不一樣,可能導致sql的執行計劃不一樣。

    不知道是否正確 ?
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月22日 0:06
  • That's true, and improper parallelism can slow down query.
    2009年9月22日 0:16


  • That's true, and improper parallelism can slow down query.


    最大并行度設置的是0(默認值)。

    從一些網站上看到:
    一般来说,如果我们看到SQL Server中有大量的CXPACKET等待类型、或者有许多查询长期处于Runnable的状态(表示该查询在等待CPU时间片),我们会建议客户将并发度降下来,以进一步排查问题。


    但是當時根本就沒看到有很多runnable或等待類型為 CXPACKET的session,所以最大并行度的設置就沒修改。




    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月22日 1:17
  • What's diference in execution plans? Tried rebuild index on those databases?
    2009年9月22日 1:48
  • CPU核由4个变为8个在生成查询计划的时候并行度会改变部分查询计划,可以改一下并行度或者你先设置一下Affintity Mask,让系统使用4个核看看是否生成的执行计划与之前相同
    通常更新硬件或大量数据后最好update statistics
    Need for Speed
    2009年9月22日 1:49



  • Hello all:

    由于恢復出來的數據庫是read-only狀態,故無法更新統計信息或重建索引。


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月22日 6:19
  • You can change that.
    2009年9月22日 15:18


  • You can change that.


    you say that I can update the statistics or rebuild the indexes in read-only database?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月23日 0:08




  • 另外一個問題,如果數據庫在使用中(生產),是否可以對日志文件進行壓縮,現在的日志文件達到60G了(3個一起)。

    我是每5分鐘進行一次日志備份,但是不知道為什么還要增加到這么大?
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月23日 0:10


  • You can change that.


    you say that I can update the statistics or rebuild the indexes in read-only database?


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    You can set database to read/write.
    2009年9月23日 1:40
  • Why need 3 log files? Don't give you any benefit. You have to find out what causes huge log, may have long running process. Check it with 'dbcc opentran'.
    2009年9月23日 1:44



  • 很奇怪的是,這三個日志文件實際的大小才幾百兆。

    為什么還增加到這么大呢?我設置的增長大小是每次256M。

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月23日 1:50



  • 很奇怪的是,這三個日志文件實際的大小才幾百兆。

    為什么還增加到這么大呢?我設置的增長大小是每次256M。

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    How big the database is? Did you check open transaction?
    2009年9月23日 1:56



  • 很奇怪的是,這三個日志文件實際的大小才幾百兆。

    為什么還增加到這么大呢?我設置的增長大小是每次256M。

    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    How big the database is? Did you check open transaction?
    the database is over 110GB.I have checked the "dbcc opentran",it shows that there is No active open transactions.
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月23日 8:39
  • Reindex will generate huge logs.
    • 已标记为答案 Wison-Ho 2009年9月25日 0:45
    2009年9月23日 16:38


  • Reindex will generate huge logs.


    yes,maybe this is the root cause.

    there is a optimization task executing on every monday.


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2009年9月25日 0:45