Скрытые возможности SQL Server

Чтобы ответить на реальный вопрос о настройке, а не смотреть на внутренние компоненты, которые могут помочь вам понять, почему SQL ведет себя так или иначе, есть только один недокументированный вариант, о котором я могу подумать.

Вы должны убедиться, что в вашем файле журнала транзакций не слишком много VLF, иначе работа журнала будет замедлена. Чтобы просмотреть количество VLF, вы должны использовать недокументированную команду DBCC LOGINFO, а затем предпринять корректирующие действия. У Кимберли есть отличный пост в блоге об этом на http://sqlskills.com/blogs/Kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

Кроме того, в перф-тюнинге нет никакой настоящей магии. Это все о правильном дизайне, правильной стратегии индексации, правильном обслуживании базы данных и повторной оценке ее снова и снова, чтобы убедиться, что ваши требования все еще удовлетворяются всем вышеперечисленным. Там нет / более быстрый переключатель для SQL Server.

Надеюсь это поможет

Существует целый ряд недокументированных команд DBCC, таких как:

DBCC PAGE и DBCC IND Это позволяет вам заглянуть внутрь механизма хранения. Пол Рэндал написал о них в блоге!

Средство просмотра внутренних компонентов SQL-сервера - гораздо более мощный инструмент, чем dbcc, для просмотра внутренних данных о том, как данные хранятся на SQL-сервере. Специально для управления разделами средство просмотра распределения позволяет сразу увидеть, какие данные находятся на каком разделе.

Вы можете получить его здесь: [ url удален... google "Internals Viewer для SQL Server" сайт:codeplex.com ]

Ключом к пониманию производительности SQL Server для любого запроса является глубокое понимание планов запросов. Определенное понимание типов используемых объединений, типов шагов выборки (сканирование против поиска) и ограничений того, что планы могут вам сказать. Например, планы запросов почти всегда портят определенные пользователем функции в списке SELECT. Но если вы поймете, как работают планы запросов, вы поймете, как работает SQL Server, как ломается, и как это исправить.

Ключом к пониманию стабильности сервера SQL Server является понимание того, как быстро прочитать журнал ошибок. Не журнал событий Windows, а настоящий текстовый файл ERRORLOG.

Ключ к найму хорошего автора запросов к SQL Server - попросить их написать с правильным синтаксисом, как использовать курсор в T-SQL. Если они получают правильный ответ, не нанимайте их, они слишком часто используют курсоры, а курсоры - почти всегда неправильный подход.

Это не документально, но одна малоизвестная "скрытая" функция - это трассировка по умолчанию. Если кто-то явно не отключает его, в SQL Server 2005 и 2008 есть системная трассировка, которая по умолчанию начинается при запуске сервера.

Это может быть очень полезно для ответа на вопрос "Что случилось?" введите вопросы после проблемы производительности. Так же хорошо, что это неоценимо для выяснения, кто был на вашем SQL Server в определенное время после инцидента безопасности.

Я узнал об этом от Джека Корбетта в его статье здесь:[1]. Джонатан М. Кехайяс также провел на этой неделе Live Meeting для PASS DBA SIG (см. Здесь:[2]).

Следующий скрипт (также от Джека Корбетта) показывает, как проверить, запущена ли трассировка по умолчанию на вашем SQL Server, и что это за файлы трассировки:

Select
    CAT.name as event_category,
    E.name as event_name,
    C.name as column_name,
    Case
        When FI.logical_operator = '0' Then 'AND'
        Else 'OR'
    End as logical_operator,
    Case   
        When FI.comparison_operator = 0 Then '='
        When FI.comparison_operator = 1 Then '<>'
        When FI.comparison_operator = 2 Then '>'
        When FI.comparison_operator = 3 Then '<'
        When FI.comparison_operator = 4 Then '>='
        When FI.comparison_operator = 5 Then '<='
        When FI.comparison_operator = 6 Then 'Like'
        When FI.comparison_operator = 7 Then 'Not Like'
    End as comparison_operator,
    FI.value as filter_value
From
    sys.traces T Cross Apply
    -- this function provides the details about the trace
    ::fn_trace_geteventinfo(T.id) EI Join
    sys.trace_events E On
        EI.eventid = E.trace_event_id Join
    sys.trace_columns C On
        EI.columnid = C.trace_column_id Join

    sys.trace_categories CAT On
        E.category_id = CAT.category_id Outer Apply
    --outer apply is like a left join as there may not be filters
    ::fn_trace_getfilterinfo(T.id) FI
--Optional
Where
    T.id = 1

- RBarryYoung

(Примечание: мне пока не доверяют гиперссылки, поэтому я получаю это)

1: www.sqlservercentral.com/scripts/Auditing/64335/

2: sqlblog.com/blogs/jonathan_kehayias/archive/2009/05/27/pass-dba-sig-default-trace-presentation-files.aspx

Я бы повторил Полу Рэндалу, что мало что не задокументировано. Сложность заключается в чтении безбожного количества документации. Я перечислил самые важные (но не настолько очевидные) в моем контрольном списке установки SQL Server:

http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install/

Вот некоторые примеры:

• Настройка безопасности для использования преимуществ мгновенной инициализации файла
• Выравнивание ваших разделов
• Используйте многолучевое распространение и поймите, как оно работает
• Не перегружайте память (люди запускают RDP в боксы и запускают вещи, так что планируйте это)