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

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

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

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

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

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

Вы можете получить его здесь: [URL-адрес удален ... google "Internals Viewer for SQL Server" site: codeplex.com]

Есть целая куча недокументированный Команды DBCC, такие как:

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

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

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

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

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

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

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

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

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

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

Я узнал об этом от Джека Корбетта в его статье здесь: [1]. Джонатан М. Кехайас также провел живую встречу для 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