April 2009

You are currently browsing the monthly archive for April 2009.

Как вы наверняка знаете, повторное исполнение команды KILL для сеанса показывает процент завершения отката прерванной инструкции. Это замечательная возможность, которая позволяет сберечь нервы администратора баз данных. Однако, есть и другие долгоиграющие команды, процент завершения которых тоже интересно было бы отслеживать. Ну, например, примерно таким же образом, как сообщает о прогрессе своей работы команда BACKUP. Вашему вниманию предлагается сценарий, который позволяет отслеживать прогресс исполнения следующих команд:

Read the rest of this entry »

В SQL Server 2008 с помощью службы SQL Server Agent и PowerShell можно достаточно просто соорудить задание, которое будет заглядывать в метаданные WMI локального или удалённого сервера, и сообщать по электронной почте, в случае если свободное место на указанном диске перешагнуло заданный порог. Ниже представлен облегчённый концепт сценария подобного задания (расписаний в нём нет и данные берутся по локальному серверу). Вам нужно будет заменить фиктивный адрес на реальный и указать почтовый профиль, если нельзя воспользоваться профилем по умолчанию.

Read the rest of this entry »

Вашему вниманию предлагается сценарий, который для каждой таблицы текущей базы данных показывает статистику по операциям INSERT, UPDATE и DELITE. Кроме этого, вы может оценить, к чему эти операции приводят, с точки зрения роста строк данных, занимаемых страниц и фрагментации. Сценарий основан на использовании двух функций динамического управления: sys.dm_db_index_operational_stats и sys.dm_db_index_physical_stats

    /* Внимание!!! Запрос исполняется несколько минут */
    SELECT  
    t.name AS [TableName]
          , fi.page_count AS [Pages]
          , fi.record_count AS [Rows]
          , CAST(fi.avg_record_size_in_bytes AS int) AS [AverageRecordBytes]
          , CAST(fi.avg_fragmentation_in_percent AS int) AS [AverageFragmentationPercent]
          , SUM(iop.leaf_insert_count) AS [Inserts]
          , SUM(iop.leaf_delete_count) AS [Deletes]
          , SUM(iop.leaf_update_count) AS [Updates]
          , SUM(iop.row_lock_count) AS [RowLocks]
          , SUM(iop.page_lock_count) AS [PageLocks]
    FROM    sys.dm_db_index_operational_stats(DB_ID(),NULL,NULL,NULL) AS iop
    JOIN    sys.indexes AS i
    ON      ((iop.index_id = i.index_id) AND (iop.object_id = i.object_id))
    JOIN    sys.tables AS t
    ON      i.object_id = t.object_id
    AND     i.type_desc IN ('CLUSTERED', 'HEAP')
    JOIN    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS fi
    ON      fi.object_id=CAST(t.object_id AS int)
    AND     fi.index_id=CAST(i.index_id AS int)
    AND     fi.index_id < 2
    GROUP BY t.name, fi.page_count, fi.record_count
          , fi.avg_record_size_in_bytes, fi.avg_fragmentation_in_percent
    ORDER BY [TableName]

Копался сегодня в одной из трассировок клиентских запросов и наткнулся на недокументированную системную хранимую процедуру (SQL Server 2008, на предыдущих не смотрел), которая позволяет узнать порядок сортировки для каждой из колонок таблицы. Вызывается она просто и результат очевиден:

Одной из трудно оптимизируемых задач SQL Server является вставка. Не раз мне приходилось сталкиваться с ситуациями, когда уже и схема оптимизирована под вставку, и сайзинг файлов вставке не препятствует, а желаемой производительности массовой или не массовой вставки достичь не удаётся. Не хватает совсем немногого…

Разработчики SQL Server 2008 позаботились о том, чтобы предоставить нам с вами в распоряжение некую «палочку – выручалочку», которая призвана как раз снизить затраты на вставку, путём её не полного журналирования. Для этого предлагается задействовать на серверах флаг трассировки 610, который по моим наблюдениям действительно может немного облегчить вставку. Флаг, и его побочные эффекты, подробно описан тут: http://msdn.microsoft.com/ru-ru/library/dd425070(en-us).aspx

Ещё одна мера, в дополнение к включению флага трассировки 610, описана в документе вендора: http://technet.microsoft.com/ru-ru/library/cc917672(en-us).aspx. Там, среди прочего, подробно описано исследование того, что будет эффективней, вставка в таблицу с единственным некластеризованным индексом, или вставка в таблицу с единственным кластеризованным индексом. Кластеризация данных может дать выигрыш на вставке до 3%.

Вот такие маленькие хитрости попались мне на глаза в документации Майкрософт. Быть может, кто-нибудь из читателей этого блога поделиться в комментариях своими маленькими хитростями?

В тему: