MS SQL Server - справа тонка
Блог для SQL Server DBA
Досвід розміщення файлів великих баз даних
У цій статті відображено досвід побудови та підтримки інфраструктури для більших (більше 10Тб) баз даних. Стаття не пропонує універсального вирішення всіх можливих завдань MS SQL Server і не відображає всієї різноманітності можливих типів навантаження. Тому використовувати наведені нижче висновки та рекомендації варто з огляду на свою специфіку. Все, що тут описано, було апробовано на OLTP навантаженнях із чималою часткою великих аналітичних запитів, агрегації, процесингу та масових вивантажень/завантажень даних. Навантаження було блокове, неоднорідне в часі та за структурою. Характерними рисами навантаження був високий паралелізм, велика кількість блокувань, гортань, асинхронних операцій, черг, очікувань процесора та закінчення введення-виведення. Саме навантаження балансувалася лише на рівні логіки роботи програми, ресурси розподілялися за можливостями завдань, запити постачалися «хінтами», а розподілу пам'яті для багатьох завдань обчислювалися десятками і сотнями Мегабайт. Стаття призначена для адміністраторів баз даних та сховищ. Очевидно, що вона полегшить розуміння особливостей розміщення файлів даних і журналів SQL Server у мережах SAN. Завантажити останній пункт »
Автоматизація перевірки баз даних
Однією з обов'язкових завдань адміністрування баз даних MS SQL Server є періодичне відновлення баз, щоб переконатися, що база успішно відновлюється. Ще одним таким завданням є періодична перевірка баз за допомогою DBCC CHECKDB. Найчастіше корисно ці завдання об'єднати і запускати перевірку бази після відновлення її на спеціально призначеному для цього сервері. Якщо база має кілька файловихгруп та розмір бази настільки великий, що перевірка кожної займає кілька годин, резонно перевіряти не всю базу відразу, а по черзі всі файлові групи. Скоротити час перевірки можна відмовившись від перевірки індексів, наприклад ось так: DBCC CHECKFILEGROUP (“PRIMARY”, NOINDEX). Read the rest of this entry »
Tips for DBA: Оповіщення про нові дампи SQL Server
Read Committed Isolation Level
SQL Server 2000 підтримував чотири рівні ізоляції транзакцій: "read uncommitted" (nolock), "read committed", "repeatable read" і "serializable". У SQL Server 2005 було додано два нові рівні ізоляції: «read committed snapshot» та «snapshot». Вказівка рівня ізоляції визначає, які блокування будуть використані SQL Server під час доступу до даних. Отже, вибір рівня ізоляції фактично визначають ступінь паралелізму та узгодженості, які стануть можливими для операцій з даними та транзакцій. Всі вказані рівні ізоляції описані в Books Online. Read the rest of this entry »
Semi-join Transformation
SQL 2016 – It Just Runs Faster: Automatic Soft NUMA
Автор: Nitin Verma - Principal SQL Server Developer, Bob Dorr - Principal SQL Server Escalation Engineer
Потужності серверного обладнання зростають рік у рік, що зумовлено багаторічним розвитком технологій виготовлення процесорів. Аналізуючи результати наших досліджень того, як працює SQL Server на сучасному устаткуванні, і як наші клієнти досягають оптимального для себе масштабування обчислювальних ресурсів, ми висунули на передній план подальшого розвитку сервера баз даних необхідність покращення можливостей секціонування обслуговування навантаження. В даний час саме заснований на секціонуванні дизайн є самимпоширеним способом локалізації обслуговування навантаження та покращення продуктивності та масштабованості. Прикладом того, як SQL Server використовує секціонування навантаження, є об'єкт CMemThread.
SQL Server 2012 Database Engine Task Scheduling
Протягом останніх років у різних джерелах було описано алгоритми роботи планувальника SQL Server. Зокрема, у статті "The Guru's Guide to SQL Server Architecture and Internals" є глава, написана розробником планувальника (Sameer) та Кеном Хендерсеном. Автор цієї статті і раніше описував деякі технічні деталі алгоритмів планування задач SQLServer.