首頁>Database>source

由於我的問题索引和 統計優化指令碼的持續時間和日志膨脹問题.正在尋找好的策略?已關闭,因為它没有足够集中,我有三个問题:

對於統計和索引優化,我想使用Ola Hallengreens指令碼。

  1. 如果我仅更新統計資訊或重建/重組索引:如果我發現日志檔案太大或作業花费的時間太长並减慢了日常工作,是否有通過取消作業中間的危险而产生的危险?

如果没有的话,我無需担心,可以在任何晚上或星期六執行它,观察它的工作原理,並在出現某些上述問题時毫無問题地取消它.這是真的吗?

  1. 如果我使用這樣配置的Olas指令碼(不重建离線索引):
  • FragmentationLevel1 = 50%
  • FragmentationLevel2 = 80%
  • FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE’
  • FragmentationHigh = ‘INDEX_REBUILD_ONLINE’
  • @UpdateStatistics nvarchar(max) = 'ALL',
  • @OnlyModifiedStatistics nvarchar(max) = 'Y',

当人们在使用資料庫時,我可以在工作期間安全地使用它吗?

  1. 通過執行此類維護工作(統計更新/索引重建/索引重組)是否存在任何危险,如果我將Ola与這些引數一起使用会损壞資料庫? 我所见過的唯一一處增长大型日志檔案的地方.還是我可以毫無後顾之忧地安裝它,如果發生任何事情,只需將其取消(請參阅問题1)?
最新回復
  • 5月前
    1 #

    對於問题1-在工作完成後取消或停止作業不会迴滚已经完成的工作,因此停止或终止執行没有任何危害。

    對於問题2-請記住,聯機索引重建仍然需要一定的鎖定,並且有關是否可以執行聯機索引存在一些限製.我將在這裏讨論這些限製.即使您可以进行線上索引重建,我也可能不会在白天執行此指令碼.索引維護可能会占用大量資源。

    問题3-Ola的指令碼不会做任何会破壞資料庫的事情。

    当我查看您的其他問题時,我不得不怀疑索引維護例程是否匯致日志檔案增长。

    您說,"由於每次資料庫更新後日志分區都已满的問题,我收到了一个不同的指令碼,可以在其中設置每个資料庫要維護的最大索引比例。但是我认為此指令碼不是 像olas指令碼一樣強大的功能,也许是因為它無法更新統計資訊或無法重建足够的索引?我最近插入了许多新資料,此後某些查詢的執行速度非常慢,這取決於資料庫。" >

    在我看来,您的部分抱怨是,在更新和更改大量資料之後,事情執行缓慢,人们建議更新統計資訊.您可以在他的網站上使用T-SQL單独进行Ola作業,如下所示。

    執行dbo.IndexOptimize @Databases ='USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics ='ALL'

  • postgresql:Postgres:从DELETE插入
  • sql server:查詢由於" ACTIVE_TRANSACTION"而匯致事務日志" tempdb"已满的原因