Які найпопулярніші проблеми щодо продуктивності, з якими ви стикаєтесь зі своїми SQL-серверами?

Я студент університету Fontys в Ейндховені, і в даний час я провожу серію інтерв'ю, щоб допомогти у розробці інструменту SQL Server, і хотів би отримати зворотній зв’язок від фахівців у цій галузі.

Одне з моїх питань:

Які найпопулярніші 3 питання щодо продуктивності, з якими ви стикаєтесь зі своїми екземплярами SQL Server, і як їх визначити?

Особливо мене цікавлять сценарії та інструменти, які використовуються для вимірювання цього.

У верхній частині голови - 3 найкращі проблеми із запитом:

• Неявні перетворення
• Погані стратегії індексації (занадто багато або недостатньо або неправильний вид)
• Використання SELECT * замість того, щоб називати лише потрібні поля

Проблеми з налаштуваннями на рівні сервера, проблеми зі схемою бази даних, проблеми з апаратним забезпеченням та ін. Я написав сценарій для швидкого аналізу серверів, які шукають такі проблеми:

http://www.brentozar.com/blitz/

• Поганий дизайн / запити / індексація
• Не дозволяється купувати правильне обладнання
• ОРМ Braindead (він же "SQL мертвий")

Не в топ-3, але думав, що я згадаю речі, про які ще не було сказано:

1. SQL розміщується на віртуальних машинах без деталей / прозорості, що надаються до DBA. Хост-сервер буде динамічно змінювати налаштування гостьових машин, викликаючи зниження продуктивності та залишаючи DBA без підказки. Такі функції, як гіпертритованість, мережеве об'єднання та балон пам’яті, роблять лічильники роботи рухомою ціллю для моніторингу.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Аналогічно, відсутність прозорості / перевіреності налаштувань SAN, наданих для DBA. У мене були задані LUN з різними налаштуваннями кешу чи запису, але сказали, що вони однакові.Tools: IO DMVs, SQLIO.
3. Погана архітектура БД: як розмір і розміщення файлів даних і журналів, і tempdb. Неправильне використання паралелізму. Створення декількох груп файлів на одних і тих же фізичних дисках.Tools: experience.

Ще один інструмент, який я перевіряю зараз, - це проект Люсі . Здається акуратно.

• відсутність належних індексів
• використання з nolock у виробничому коді ким-небудь, щоб спробувати вирішити проблеми з продуктивністю. Особливо погано, якщо код змінює дані в таблицях
• додаток, що вибирає більше даних, ніж потрібно в більше разів, ніж це потрібно. Наприклад, кожен бінарний файл повертається кожен раз, навіть якщо ви просто хочете текстові дані тієї ж таблиці.

Запити, які погано масштабуються (отримуйте всі замовлення протягом X років для всіх клієнтів тощо, включаючи всі лінії замовлень, включаючи підсумовані дані та інші середні дані, погано розраховані)

Просто запитуйте все одразу.

Таблиці, що містять "описові" варшар / текстові поля, які потрібно шукати через кожен запит.

• Неправильне обслуговування, тобто відсутність перегляду журналів, статистики, резервного копіювання журналу
• Відсутні індекси
• Погано написані запити

• Погана база даних та дизайн додатків
• недостатнє використання переваг платформи (розробники хотіли мати платформенний код доступу до бази даних. Ніяких SP, ніяких функцій тощо)
• погана індексація, звичайно.

• спеціальні запити щодо даних про продажі - так, розробники вважають, що це потрібно, а деякі можуть навіть мати доступ :-)
• поганий дизайн програми, яка використовує базу даних - наприклад: занадто багато даних додаються і ніколи не видаляються, навіть якщо це більше не потрібно (що призводить до проблем з продуктивністю, оскільки резервні копії зростають, завдання з обслуговування займають більше часу ... тощо)
• всі файли баз даних на тому ж рейді або гірше, на одному диску (наприклад: системний dbs, tempdb, користувальницький dbs всі разом на одному диску / raid)

• Поганий дизайн бази даних
• Погана стратегія індексації (включаючи занадто багато індексів, відсутні індекси та відсутність обслуговування індексу)
• Погані апаратні архітектурні рішення

Індексація має вирішальне значення для продуктивності, але я виявив, що більшість DBA знають про це, і тому це, як правило, одна з перших речей, яка виправляється за допомогою оптимізації запитів. Сфери, які часто недостатньо добре адресовані:

1. Занадто багато об’їздів БД. Балакучість - одна з головних проблем роботи.
2. Отримання правильних меж транзакцій. Здійснення трансакцій кожного INSERT / UPDATE / DELETE може бути вбивцею великої продуктивності.
3. Нездатність оптимізувати апаратну сторону; зокрема, розміщення журналу БД відрізняється від даних БД.

Якби я міг додати до списку четвертий пункт, це було б надмірним і недоцільним використанням тригерів та / або курсорів. Здається, це не надто багато в наші дні, але коли це відбувається, це болісно з точки зору виступу.