Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Есть ли что-то страшное в этом скрипте?  [new]
MAULER
Member

Откуда:
Сообщений: 882
Приветствую. Сервер SQL 2005 Standard

Проблема в том, что с определенного времени работа с <Базой данных> стала замедляться, клиентская часть у юзеров "время от времени" подвисает. В базе лежат документы, другими словами это СЭД. В скл агенте работают задачи и вроде бы все ок, но жуткие тормоза.

Стало появляться подозрение, что дело в индексах. Почему:

Запрос
DECLARE @db_id SMALLINT;
SET @db_id = DB_ID(N'DIRECTUM_STUDY');
select * from sys.dm_db_index_physical_stats (@db_id, NULL, NULL, NULL, 'DETAILED')

в столбце avg_fragmentation_in_percent показывает для некоторых индексов процент фрагментации 96%

А вопрос вот в чем: Можно ли для базы сэд использовать скрипт по перестроению индексов, который приводится на сайте MS, а именно:

-- ensure a USE <databasename> statement has been executed first.
SET NOCOUNT ON;
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname sysname;
DECLARE @objectname sysname;
DECLARE @indexname sysname;
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command varchar(8000);
-- ensure the temporary table does not exist
IF EXISTS (SELECT name FROM sys.objects WHERE name = 'work_to_do')
    DROP TABLE work_to_do;
-- conditionally select from the function, converting object and index IDs to names.
SELECT
    object_id AS objectid,
    index_id AS indexid,
    partition_number AS partitionnum,
    avg_fragmentation_in_percent AS frag
INTO work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;
-- Declare the cursor for the list of partitions to be processed.
DECLARE partitions CURSOR FOR SELECT * FROM work_to_do;

-- Open the cursor.
OPEN partitions;

-- Loop through the partitions.
FETCH NEXT
   FROM partitions
   INTO @objectid, @indexid, @partitionnum, @frag;

WHILE @@FETCH_STATUS = 0
    BEGIN;
        SELECT @objectname = o.name, @schemaname = s.name
        FROM sys.objects AS o
        JOIN sys.schemas as s ON s.schema_id = o.schema_id
        WHERE o.object_id = @objectid;

        SELECT @indexname = name 
        FROM sys.indexes
        WHERE  object_id = @objectid AND index_id = @indexid;

        SELECT @partitioncount = count (*) 
        FROM sys.partitions
        WHERE object_id = @objectid AND index_id = @indexid;

-- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding
IF @frag < 30.0
    BEGIN;
    SELECT @command = 'ALTER INDEX ' + @indexname + ' ON ' + @schemaname + '.' + @objectname + ' REORGANIZE';
    IF @partitioncount > 1
        SELECT @command = @command + ' PARTITION=' + CONVERT (CHAR, @partitionnum);
    EXEC (@command);
    END;

IF @frag >= 30.0
    BEGIN;
    SELECT @command = 'ALTER INDEX ' + @indexname +' ON ' + @schemaname + '.' + @objectname + ' REBUILD';
    IF @partitioncount > 1
        SELECT @command = @command + ' PARTITION=' + CONVERT (CHAR, @partitionnum);
    EXEC (@command);
    END;
PRINT 'Executed ' + @command;

FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag;
END;
-- Close and deallocate the cursor.
CLOSE partitions;
DEALLOCATE partitions;

-- drop the temporary table
IF EXISTS (SELECT name FROM sys.objects WHERE name = 'work_to_do')
    DROP TABLE work_to_do;
GO

а в конце всего этого хозяйства сделать:
use [База данных]
go
exec sp_updatestats
9 ноя 09, 09:32    [7899696]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли что-то страшное в этом скрипте?  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
MAULER
...Можно ли...
А почему - нет?
Сделайте тестовую базу (восстановите из резервоной копии продуктивной) и попробуйте...
9 ноя 09, 09:36    [7899712]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли что-то страшное в этом скрипте?  [new]
MAULER
Member

Откуда:
Сообщений: 882
Я также подумал, но подрубать юзеров к этой "тестовой" базе будет очень геморойно, к тому же копию то я сделаю, а как проверить, что юзеры "чувствуют" улучшение, если они как работали в рабочей базе - так и будут работать.
9 ноя 09, 09:38    [7899725]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли что-то страшное в этом скрипте?  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
MAULER
Я также подумал, но подрубать юзеров к этой "тестовой" базе будет очень геморойно, к тому же копию то я сделаю, а как проверить, что юзеры "чувствуют" улучшение, если они как работали в рабочей базе - так и будут работать.
В данном случае, вы в тестовой базе проверите, что скрипт вам ничего не сломает.
А вот на производительность смотреть надо после его прогона в продуктиве.
9 ноя 09, 09:45    [7899762]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли что-то страшное в этом скрипте?  [new]
Crimean
Member

Откуда:
Сообщений: 13148
а что, перестроение индексов что-то может сломать? оо!
тада воспользуйтесь задачами по обслуживанию базы данных!
9 ноя 09, 09:50    [7899787]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли что-то страшное в этом скрипте?  [new]
MAULER
Member

Откуда:
Сообщений: 882
Crimean
а что, перестроение индексов что-то может сломать? оо!
тада воспользуйтесь задачами по обслуживанию базы данных!


Эти задачи есть, и они работают, причем задачи от самого разработчика, но есть сомнение, что задачи эти никак на скорость не влияют.
9 ноя 09, 09:53    [7899798]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить