Очень большие таблицы в SQL Server

Question

У нас очень большая таблица (> 77M записей и рост), работающая на SQL Server 2005 64bit Standard Edition, и мы видим некоторые проблемы с производительностью. Ежедневно добавляется до сотни тысяч записей.

Кто-нибудь знает, существует ли ограничение на количество записей SQL Server Standard Edition может обрабатывать? Должно быть, нужно переходить к изданию Enterprise или есть какие-то трюки, которые мы можем использовать?

Дополнительная информация:

В таблице вопрос довольно плоский (14 столбцов), есть кластерный индекс с 6 полей, а два других индексов на отдельных полях.

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

Answer 1

[есть кластерный индекс с 6 полей, а два других индексов на отдельных полях.]

Не зная никаких подробностей о полях, я хотел бы попытаться найти способ уменьшить кластеризованный индекс.

С SQL Server все поля кластеризованного ключа также будут включены во все некластеризованные индексы (как способ сделать окончательный поиск с некластеризованного индекса на фактическую страницу данных).

Если у вас есть шесть полей по 8 байт каждый = 48 байт, умножьте это на два больше индексов, умноженное на 77 миллионов строк, - и вы смотрите на много потерянного пространства, которое переводится во множество операций ввода-вывода (и, следовательно, ухудшает производительность).

Для кластеризованного индекса это абсолютно CRUCIAL, чтобы он был уникальным, стабильным и как можно меньшим (предпочтительно одним INT или таким).

Марк

Answer 2

http://msdn.microsoft.com/en-us/library/ms143432.aspx

У вас есть некоторые возможности для роста.

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

Answer 3

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

Для этого вам, безусловно, не нужно переходить на Enterprise edition.

Answer 4

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

Помимо этого, вы можете рассмотреть разбивку таблицы. Это позволит вам разделить таблицу на несколько логических групп. Вы можете сделать это «за кадром», поэтому он по-прежнему отображается в sql-сервере как одна таблица, даже если он хранится отдельно, или вы можете сделать это вручную (создать новый «архив» или годовую таблицу и вручную переместить по строкам) , В любом случае, только сделайте это после, вы сначала посмотрели на другие варианты, потому что, если вы не получите это право, вам все равно придется проверять каждый раздел. Также: разбиение делаетrequire Enterprise Edition, так что это еще одна причина, чтобы сохранить это в крайнем случае.

Answer 5

Само по себе 77M-записи не так много для SQL Server. Как вы загружаете 100 000 записей? является ли загрузка пакетов каждый день? или через какое-то приложение OLTP? и что проблема с производительностью, которую вы имеете, то есть добавление данных? или это запрос, который дает вам больше всего проблем?

Если вы добавляете 100 тыс. Записей за раз, а добавляемые записи заставляют кластер-индекс перегруппировать таблицу, это быстро приведет к быстрому удалению вашей производительности. Более подробная информация о структуре таблицы, индексах и типе вставленных данных поможет.

Кроме того, количество баранов и скорость ваших дисков будут иметь большое значение, на чем вы работаете?

Answer 6

Какие у вас есть диски?

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

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

Answer 7

Вам действительно нужно иметь доступ ко всем 77 миллионам записей в одной таблице?

Например, если вам нужен только доступ к последним данным за X месяцев, вы можете подумать о создании стратегии архивации. Это можно использовать для переноса данных в таблицу архивов, чтобы уменьшить объем данных, а затем, время запроса на вашей «горячей» таблице.

Этот подход может быть реализован в стандартной редакции.

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

Вот отличный Белая бумага на секционирования таблиц в SQL Server 2005

http://msdn.microsoft.com/en-us/library/ms345146.aspx

Я надеюсь, что я подробно ясно и понятно. Пожалуйста, свяжитесь со мной напрямую, если вам нужна дополнительная помощь.

Приветствия,

Answer 8

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

Уникальность не требуется для кластеризованного индекса. На самом деле, лучшие кандидаты для полей, которые должны быть в кластерном индексе, являются теми, которые не уникальны и не используются в объединениях.Например, в таблице Persons, где каждый Person принадлежит одному Group, и вы часто присоединяетесь к Persons до Groups, при этом доступ к партиям людей по группам Person.group_id был бы идеальным кандидатом для этого конкретного варианта использования.

Answer 9

Согласие с Marc и Unkown выше ... 6 индексов в кластерном индексе слишком много, особенно на таблице с 14 столбцами. У вас должно быть не более 3 или 4, если это так, я бы сказал 1 или, возможно, 2. Вы можете знать, что кластеризованный индекс является фактической таблицей на диске, поэтому, когда запись вставлена, механизм базы данных должен сортировать ее и поместите его в свое отсортированное организованное место на диске. Без кластеризованных индексов нет, они поддерживают поиск «таблиц». Мои VLDB выкладываются на диск (CLUSTERED INDEX) в соответствии с 1-м пунктом ниже.

1. Снизить кластерный индекс 1 или 2. Лучший выбор полей являются IDENTITY (INT), если у вас есть один или поле даты, в котором поля добавляются в базу данных, или некоторые другие поля это естественный вид того, как ваши данные добавляются в базу данных. Дело в том, что вы пытаетесь сохранить эти данные в нижней части таблицы ... или выложили на диск лучший (90% +) способ, по которому вы будете читать записи. Это делает его таким, что не происходит реорганизации или что он принимает один и только один удар, чтобы получить данные в нужном месте для лучшего чтения. Обязательно поместите удаленные поля в некластеризованные индексы, чтобы не потерять эффективность поиска. Я НИКОГДА не клал более 4 полей на свои VLDB. Если у вас есть поля, которые часто обновляются, и они включены в ваш кластерный индекс, OUCH, это собирается реорганизовать запись на диске и вызвать фрагментацию COSTLY.
2. Проверьте заполняющий фактор на ваших индексах. Чем больше значение коэффициента заполнения (100), тем больше будет страниц данных и индексных страниц. В отношении того, сколько записей у вас есть и сколько записей вы вставляете, вы измените fillfactor # (+ или -) ваших некластеризованных индексов, чтобы разрешить заполнять пространство при вставке записи. Если вы измените свой кластеризованный индекс на поле последовательных данных, это не будет иметь особого значения для кластерного индекса. Эмпирическое правило (IMO), 60-70 fillfactor для высокой записи, 70-90 для записи в среде и 90-100 для высоких чтений/низкой записи. Отбрасывая ваш fillfactor до 70, будет означать, что на каждые 100 записей на странице записано 70 записей, из-за чего будет свободное место 30 записей для новых или реорганизованных записей. Ешьте больше места, но он уверен, что каждый раз нужно DEFRAG (см. Ниже).
3. Убедитесь, что статистика существует на столе. Если вы хотите подметать базу данных для создания статистики, используя «sp_createstats» indexonly », тогда SQL Server создаст все статистические данные по всем индексам, которые накопители накопили, требуя статистики. Не оставляйте атрибут 'indexonly', хотя вы добавите статистику для каждого поля, что тогда не будет хорошим.
4. Проверьте таблицу/индексы с помощью DBCC SHOWCONTIG, чтобы узнать, какие индексы становятся фрагментированными больше всего. Я не буду вдаваться в подробности здесь, просто знайте, что вам нужно это сделать. Затем, основываясь на этой информации, измените fillfactor вверх или вниз по отношению к изменениям, которые индексы испытывают изменения и насколько быстро (с течением времени).
5. Настройка расписания работы, которое будет выполняться в режиме онлайн (DBCC INDEXDEFRAG) или в автономном режиме (DBCC DBREINDEX) для отдельных индексов для их дефрагментации. Предупреждение: не делайте DBCC DBREINDEX на этом большом столе без необходимости во время обслуживания, потому что это приведет к снижению приложений ... особенно в CLUSTERED INDEX. Вас предупредили. Протестируйте и проверьте эту часть.
6. Используйте планы выполнения, чтобы увидеть, какие существуют SCANS и FAT PIPES, и отрегулируйте индексы, затем дефрагментируйте и перепишите хранимые процедуры, чтобы избавиться от этих горячих точек. Если вы видите RED-объект в своем плане выполнения, это связано с тем, что в этом поле нет статистики. Плохо. Этот шаг - скорее «искусство, чем наука».
7. В нерабочее время запустите СТАТИСТИКУ ОБНОВЛЕНИЯ С FULLSCAN, чтобы предоставить серверу запросов столько информации о распределении данных, сколько сможете.В противном случае сделайте стандартную СТАТИСТИКУ ОБНОВЛЕНИЯ (со стандартным сканированием 10%) в таблицах во время недельных или более часто, как вы сочтете нужным для своих наблюдений, чтобы убедиться, что у двигателя больше информации о распределении данных для эффективного извлечения данных.

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

Не нужно идти в Enterprise edition. Я сделал это, чтобы получить функции, о которых говорилось ранее, с разделением. Но я ОСОБЕННО имел намного лучшие возможности многопоточности с поиском и онлайн-DEFRAGING и обслуживанием ... В Enterprise edition гораздо лучше и дружелюбнее с VLDB. Стандартная версия не обрабатывает DBCC INDEXDEFRAG с онлайн-базами данных.

Answer 10

Возможно, это незначительные ники, но .... (1) реляционные базы данных не имеют ПОЛЯ ... у них есть КОЛОНКА. (2) Столбцы IDENTITY обычно означают, что данные не нормализованы (или дизайнер ленился). Некоторая комбинация столбцов ДОЛЖНА быть уникальной (и эти столбцы составляют первичный ключ) (3) индексирование столбцов datetime обычно плохое; CLUSTERING в столбцах datetime также является плохой идеей, особенно постоянно растущим столбцом datetime, поскольку все вставки конкурируют за одно и то же физическое пространство на диске. Кластеризация столбцов datetime в таблице только для чтения, где этот столбец является частью ограничений диапазона, часто является хорошей идеей (см., Как конфликтуют идеи, кто сказал, что дизайн db не был искусством ?!)