Вопросы Теги

Размер строки, индексы и varchar (макс.)

Будьте осторожны. Некоторые файлы могут просто сообщения, который задержался из-за проблем с целевым сервером и собирается быть снова посланным.

Попытайтесь видеть, можно ли промыть очередь сначала. Если это не работает, начните очищать сообщения от той очереди. С некоторыми почтовыми системами (т.е. Постфикс), существует особенный метод очистить очередь. Вот один подряд из страницы справочника для постсупер:

       -d queue_id
          Delete one message with the named queue ID from the named mail queue(s) (default: hold, incoming, active and deferred).

          If a queue_id of - is specified, the program reads queue IDs from standard input. For example, to delete all mail with exactly one recipient user@example.com:

          mailq | tail +2 | grep -v '^ *(' | awk  'BEGIN { RS = "" }
              # $7=sender, $8=recipient1, $9=recipient2
              { if ($8 == "user@example.com" && $9 == "")
                    print $1 }
          ' | tr -d '*!' | postsuper -d -

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

2
задан 21 April 2011 в 21:56
3 ответа

Нет в основном никакого различия между VARCHAR(2048) и VARCHAR(MAX). Каждый подвергается переполнению в 'единицу выделения' переполнения строки, другой подвергается переполнению в единицу выделения BLOB, посмотрите Организацию Таблицы и Индекса. Настройка по умолчанию large value types out of row опция таблицы 0 так, если она не была изменена, VARCHAR(MAX) останется последовательно, если это возможно, точно так же, как VARCHAR(2048) был бы.

Я рекомендовал бы работать sys.dm_db_index_physical_stats и получая фактическое макс., минута и в среднем размер строки, а также avg_page_space_used_in_percent. Это даст больше точной картины истинного размера (размеров) строки, а не теоретического заявленного размера.

2
ответ дан 3 December 2019 в 11:05

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

SSMS иногда имеет полезную информацию, где индексы могут отсутствовать:
http://msdn.microsoft.com/en-us/library/ms345524%28v=SQL.100%29.aspx

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

1
ответ дан 3 December 2019 в 11:05

Запросы записаны так, чтобы они только запросили данные, в которых они нуждаются, т.е. никакой ВЫБОР *?

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

0
ответ дан 3 December 2019 в 11:05

Теги

Похожие вопросы