Вопрос о производительности SQL Server 2008

Question

У меня есть таблица с 30 столбцами и около 3,4 миллиона записей. Это разумно для SELECT * FROM [Таблица]; взять от 8 до 12 минут, чтобы вернуть все 3,4 миллиона результатов?

Если нет, где хорошее место/ресурс, чтобы начать диагностировать мою проблему?

Answer 1

Скорее всего, SQL-сервер делает все возможное, чтобы получить данные, которые вы просили. Неплохо предположить не менее 1K/записи для 30 столбцов. 3.4M x 1K = 3.4Gb.

Только чтение 3,4 ГБ с диска может занять несколько минут на средней машине (не забывайте, что это не просто читать, есть, очевидно, некоторые обработки SQL накладные расходы в нем.

Но, конечно, в реальном сценарии вы не хотите получать все данные ...

Answer 2

Да, разумно. Для системы, которая тонко настраивается и управляется оптимально, может доставлять 3,4 мил строк за 12 минут, это точно ожидаемый результат ...

Тем не менее, некоторые места для улучшения производительности:

• Соответствует ли таблица буферному пулу? То есть. у вас достаточно ОЗУ для хранения всей вашей базы данных? Если нет, тогда вы собираетесь нажать диск для ввода-вывода. Page life expectancy Счетчик хороший индикатор.
• Насколько быстро ваша подсистема ввода-вывода диска? Речь идет о 5000-миллисекундном драйвере IDE или RamSAN-500? Какова пропускная способность, сообщенная sqliosim? Как насчет перманентных счетчиков, Avg. Длина очереди диска, сред. Disk Sec/Transfer на физических дисках? Разве это отличается от Reads vs. Writes?
• Насколько фрагментирован стол? Производительность сканирования зависит прежде всего от эффективности чтения и скорости чтения, определяемой размером фрагмента hobt. Возможно, вам нужно оптимизировать ETL таблицы, следуйте методологии FastTrack.
• Какие-либо разногласия продолжаются? Вы измеряли время ожидания блокировки? Возможно, изоляция snasphot может облегчить проблему.
• Может ли клиент получить 3,4 млн. Строк во времени? Обеспечивает ли сервер блокирование доступности буферов клиентов? Опять же, статистика ожидания может указывать на это.

Еще одно хорошее место для начала - следовать методологии Wait and Queues.

Answer 3

Есть так много вопросов, которые могут быть заданы в отношении дискового ввода-вывода, размера столбцов и других связанных с настройкой объектов. Если вы находитесь на действительно очень медленном диске и медленной сети, это не займет 12 минут.

Первое, что нужно посмотреть, это план выполнения. Это должно дать вам представление о том, как SQL Server обрабатывает вещи.

Пара вопросов, которые я хотел бы попросить лучше устранить неполадки? Есть ли первичный ключ? Он сгруппирован? Есть порядок?

Answer 4

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

Если ваш ответ длится 8-12 минут, значит, у вас нет проблем, что всегда хорошо.

Если ваш ответ меньше этого, то теперь вы знаете, что у вас есть проблема, и насколько велика проблема (если вы сказали 5 минут, то, возможно, это не такая большая проблема, если вы сказали 10 секунд, то это гораздо большая проблема). В этом случае вы, вероятно, захотите начать просмотр счетчиков производительности базы данных, чтобы узнать, есть ли у него узкие места с CPU/IO/памятью/сетью, и посмотрите на план выполнения запроса, чтобы узнать, можно ли его улучшить с помощью индексов (хотя это маловероятно для SELECT *).

Answer 5

Возможно, было бы более интересно оценить запросы, которые ваша система фактически работает. Средство Profiler, поставляемое с SQL Server, может регистрировать все запросы, которые выполняет ваша система. Пусть он запускается в течение определенного периода (при условии, что у вас есть достаточное количество дополнительного дискового пространства), и он будет записывать, какие запросы выполняются, и заданные параметры. Он также расскажет вам, как долго они все должны были выполнить.

Посмотрите на это и выясните, какие запросы используют ваше процессорное время, помогут вам разобраться, куда идти для настройки производительности - например, если Query A занимает 60 секунд, и запускается только один раз в день, это может оказать большое влияние на это приложение, чтобы настроить его, но настройка того, что один запрос не заставит ваш SQL Server быстрее. Но если Query B занимает 2 секунды для запуска и работает 4000 раз в день, настройка может иметь большее общее влияние.

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

Answer 6

Разумный по сравнению с чем?

1. Насколько широки ряды?
2. Как быстро ваш процессор?
3. Сколько у вас RAM?
4. Является ли таблица уже в ОЗУ при запуске запроса?
5. Выполняете ли вы результаты по сети? Если да, то как быстро?
6. Как быстро клиент, который извлекает строки?
7. Как быстро ваши диски?
8. Насколько фрагментирован стол?
9. Является ли машина БД делать что-нибудь еще в одно и то же время?

Answer 7

Я согласен с вами, я только что возвратил 20 миллионов строк данных с сервера SQL 2008 менее чем за 3 минуты - стоимость оборудования меньше, чем лицензия SQL.

Если ваше оборудование/сеть действительно не всасывается, тогда производительность может быть достигнута где-то.