Как увеличить производительность Базы данных?

Есть много вещей, которые вы могли бы сделать, многие из них уже были предложены выше. Некоторые из них я бы посмотрел (в таком порядке):

• Ошибки/журналы - во многих db-движках есть отчетные инструменты, которые указывают на проблемные области в базе данных. Начните здесь, чтобы посмотреть, есть ли что-нибудь, на чем можно сразу сосредоточиться.
• Сохранение данных - проверьте спецификацию бизнеса, как долго должны храниться данные, убедитесь, что все старые данные перенесены в хранилище данных, чтобы сохранить размер таблиц небольшим. (Зачем хранить данные за 5 лет, если нужно только последние 3 месяца?)
• Ищите сканы таблиц, индексируйте данные, если это поможет (вы должны сравнивать их с данными о записях таблиц). Логи вашего сервера, вероятно, могут помочь вам в поиске сканов таблиц.
• Атомные элементы работы, некоторые записи сохраняют блокировки на разных таблицах до достижения точки коммита? Можно ли упростить эти элементы работы или переместить точки коммита для ускорения производительности? Здесь вам понадобится разработчик, чтобы посмотреть на код.
• Ищите длинные SQL-запросы, можно ли сделать их более эффективными? Иногда плохо структурированные запросы могут действительно загромождать приложение. Возможно, вам понадобится предложить изменение кодирования для повышения производительности.
• dba realm: посмотрите, как распределяются таблицы: размер страницы, несколько сегментов и т.д. Здесь могут пригодиться средства диагностики от производителя, так как они часто могут подсказать, как можно структурировать таблицу на основе истории использования. Опытный dba будет полезен здесь.
• ищите узкие места в аппаратном обеспечении/сети. Здесь вам понадобится парень с аппаратным обеспечением. :)

Это действительно высокий уровень, я бы также взглянул на то, что предлагает производитель вашего db-движка в качестве улучшения производительности.

Также, я бы сравнил этот список с тем, за что мой босс готов платить и сколько времени у меня есть. ;)

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

Мы не писали об одном бите производительности:

Аппаратное обеспечение.

Базы данных интенсивно управляются вводом/выводом данных. Переход на более быстрый жесткий диск должен увеличить скорость запросов к БД. Разделение базы данных на множество быстрых жестких дисков может улучшить ее еще больше

Это очень расплывчатый вопрос.

Вы говорите, что ищете индексацию, но не можете смотреть на индексацию по отдельности. Вы должны посмотреть на выполняемые запросы, планы выполнения, используемые индексы и то, как они используются. Инструмент Профилировщик может очень помочь в определении того, какие запросы неэффективны.

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

Если у вас есть инфраструктура, посмотрите в настройках файла и файловой группы. Попробуйте по возможности разместить таблицы и/или индексы, которые имеют большой размер и часто используются на разных физических дисках. Если у вас очень большие таблицы, вы можете подумать о их разметке.

Если у вас все еще есть проблемы с производительностью, иногда может помочь денормализация - но все зависит от ситуации.

Я остановлюсь на этом - не хочу, чтобы этот ответ стал самым случайным в мире списком подсказок по производительности SQL. Я рекомендую вам уточнить, где, по вашему мнению, проблемы с производительностью, и рассказать нам немного больше о базе данных (размер, текущая стратегия индексации, частота транзакций, любые большие отчеты, которые вам нужно сгенерировать и т.д.)

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

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

Вы также можете использовать динамические представления и функцию управления, чтобы узнать, какие индексы отсутствуют. Вы также сможете получить статистику по существующим индексам, таким как использование индексов и пропущенные индексы.

Оптимизация запросов, используемых для доступа к этой базе данных, является наиболее важной. Просто добавляя индексы, вы не гарантируете, что запросы будут их использовать.

]К вашему инструментарию нормализации и индексирования, с чрезвычайно большими таблицами, вы можете также рассмотреть плюсы и минусы партиционирования таблиц. Но ключевые таблицы у вас уже есть.[

][]Compression[]. Для подавляющего большинства нагрузок, которые я пробовал, использование компрессии было огромной свободной ездой. Уменьшение объема данных означает уменьшение количества входов/выходов и увеличение пропускной способности. В SQL Server 2005 возможности сжатия ограничены ([]vardecimal[]). Но я бы серьезно подумал об апгрейде до 2008 года только для сжатия страниц. Или 2008 R2, если вы часто используете []nvarchar[] для получения юникодного сжатия.[

][]Data Retention[]. Установление политики хранения и агрессивное удаление старых данных. Меньшее количество данных означает меньшее количество входов/выходов, означает большую пропускную способность. Часто это рассматривается как операционная, а не дизайнерская работа, но мне нравится думать об этом как о проблеме дизайна приложения.[

] Конечно, я предполагаю, что вы уже отслеживаете каждый запрос, чтобы убедиться, что ни один из них не выполняет глупое сквозное сканирование таблиц. [

] Многие другие устройства повышения производительности в основном работают или развертываются, а не проектируются: техническое обслуживание (дефрагментация, восстановление индекса и т.д.), проектирование входов/выходов и хранилищ и т.д. [

] И последнее, но не менее важное - понять скрытую стоимость различных решений "под ключ". Например, репликация или зеркалирование баз данных [

Моим роллом на MySpace был "DBA/Developer enhancement enhancement performance DBA/Developer". Я бы сказал, что нормализация и индексы являются требованием к высокопроизводительным базам данных, но вы должны действительно анализировать структуры таблиц и индексов, чтобы по-настоящему раскрыть возможности проектирования баз данных.

Вот несколько предложений, которые я хотел бы сделать для вас;

1. Познакомьтесь с движком БД. Сквозь знание основной структуры ввода/вывода вы пройдете очень долгий путь в проектировании правильного индекса или таблицы. Используя PerfMon и Profiler, наряду с вашими знаниями о том, что такое чтение/запись ввода/вывода, вы можете поместить некоторые очень специфические числа в вашу теорию о том, что такое хорошо сформированная таблица/индекс.

2. Поймите разницу между кластерными и некластерными индексами и когда их использовать.

3. Используйте sys.dm_os_waiting_tasks и sys.dm_os_wait_stats DMV. Они подскажут вам, куда следует приложить усилия для сокращения времени ожидания.

4. Используйте DBCC SET STATISTICS IO/TIME ON и оцените ваши планы выполнения, чтобы увидеть, уменьшает ли один запрос или увеличивает количество чтений страницы или длительность.

5. DBCC SHOWCONTIG сообщит вам, если ваши таблицы сильно фрагментированы. Это часто игнорируется разработчиками и DBA-младшими с точки зрения производительности - однако, это может иметь очень большой эффект на количество прочитанных страниц. Если таблица имеет 20-процентную плотность страниц, это означает, что вы читаете примерно в 5 раз больше данных, чем если бы таблица и ее индексы были дефрагментированы.

6. Оцените грязные прочтения ( nolock, read uncommited ). Если бы вы могли обойтись без миллисекундной точности на чтениях, сохраните замки!

7. Подумайте о том, чтобы убрать ненужные Иностранные ключи. Они полезны в средах Dev, а не на высокопроизводительных транзакционных системах.

8. Разделы в больших таблицах имеют большое значение - только при правильном проектировании.

9. Изменения в приложениях - Если бы вы могли запланировать пакетные обновления для асинхронных транзакций, поместите их в безиндексную кучу и обработайте их по расписанию так, чтобы не производить последовательное обновление таблиц, к которым вы обращаетесь с большими запросами.

10. Always Always Always!!! использует одну и ту же переменную типа данных для запроса целевых столбцов; например, в следующем операторе для столбца типа Smallint используется переменная типа bigint:

объявить @i bigint set @i = 0

select * from MyTable where Col01SmallInt >= @i

В процессе обработки индексных/табличных страниц движок запросов может принять решение о преобразовании данных из столбцов с малым размером в данные с большим размером. Вместо этого подумайте об изменении типа varialbe, или о последнем преобразовании его в bigint в условиях поиска.

11. SQL 2005/08 предоставляет вам "Отчеты" в приложении "Управление", посмотрите на отчеты о том, как работают ваши индексы. Сканируются ли они, ищут ли их? когда вы последний раз сканировали таблицу? Если это был последний раз, то вы выполняете не все необходимые запросы. Если у вас есть индекс, который едва ли используется (ищется или сканируется), но постоянно обновляется, подумайте об его удалении... Это может сэкономить вам массу ненужных блокировок рядов и клавиш. ..

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