Comments 10
Вопросы к вашим пунктам.
- Чем в вашем контексте отличается процесс настройки и сами настройки "обычной" БД от "облачной"? Из статьи не видно.
- О выборе оптимальных параметров использования памяти MS SQL Server можно прочитать здесь. — там почти только о том как настроить, но не какое значение выбрать.
- О выборе оптимальных параметров MaxDOP можно прочитать здесь. — там почти только о том как настроить, но не какое значение выбрать. Не засвечена связанная настройка cost threshold for parallelism.
- trace flags: Так какие и почему флаги используете? Просто кинуть "а вон, ищи среди пары сотен нужные" это как-то даже некультурно для статьи.
- tempdb: Почему вы приводите ссылку на "пенсионерские" рекомендации для SQL Server 2008 R2? Её ж скоро уже с поддержки снимут. И эти рекомендации не работают при 64+ процессорах (а это уже двухсокетник AMD Epyc). Вообще по всей статье сплошные отсылки к рекомендациям 10+ лет.
- Как вы боретесь с узкими местами в tempdb? Если у вас 50-60 клиентов начнут её активно использовать явно или неявно (udf или неудачный план могут очень неявно её грузить), что нельзя запретить, то именно tempdb обычно становится главным узким местом.
- "Корректно настраиваем параметры дефолтных расположений дата-файлов/лог-файлов" — так какие параметры корректные и почему?
- Disk Partition Alignment — Эмм… Вы сами-то смотрели, когда это в последний раз было актуально, и какая версия windows стала сама нормально форматировать?
- 64 КБ кластер всегда и для всех? Хм. Это требует обоснования.
- Вообще по настройкам дисковой подсистемы очень неплохо начать с Microsoft SQL Server Best Practices And Design Guidelines For EMC Storage — даже если у вас не EMC. Просто чтобы понять что настраивать и в какую сторону дальше читать. Если бы все админы СХД перед тем как общаться с DBA читали это, то это бы сэкономило пару ГЭС электроэнергии и миллиардов долларов.
- Настраиваем "Мгновенную инициализацию файлов базы данных" — что вы делаете, чтобы она не включилась?
- RCSI — как вы боретесь с тем, что RCSI потенциально делает tempdb сервера узким местом?
- Page Verify — еще одна рекомендация прошлого века. Если БД создавалась не 20 лет назад, то она будет CHECKSUM. А если и Torn pages, то клиент сам себе злобный буратин в случае поломки. По "Page Verify", Auto Shrink, Auto Close, Auto Create Statistics и Auto Update Statistics вам проще было сразу в статью запрос написать. Ну или вообще отправить к Бренту Озару или даже сразу сюда
- "Дата-файл/ы и лог-файл БД размещаем на отдельных физических дисках". Там тема не столько про распараллеливание, сколько про то, что журнал транзакций это критичная по скорости write-ahead последовательная запись на диск и любая другая дисковая активность превращает её из последовательной в произвольную с увеличением latency примерно на порядок на дисках. На SSD это не всегда так (см выше статеечку от EMC), но пока потенциальный выигрыш от этого пока, наверное, выше, чем затраты на управление.
- "Выбираем корректные начальные размеры дата-файла/ов и лог-файла БД", "Выбираем корректные параметры “Авто-роста” для дата-файла/ов и лог-файла БД" — а какие именно настройки корректные для облачных БД и почему?
- "Выполняем проверку целостности данных БД" — как вы это делаете для облачной БД? Как выбираете окно и как делаете, что это не влияет на остальные БД?
- "Выполняем кастомный index rebuild/reorganize в зависимости от фрагментации индексов" — каким инструментом? Чем это отличается от скриптов Ola Hallengren ?
- "Обновляем статистику". Неудачное объяснение. Статистику приходится обновлять явно в первую очередь для того, чтобы не попасть на обновление статистики в "горячее время", во вторую, чтобы обновлённая статистика дала потенциально лучший план запроса. Но если вы обслуживаете индексы, если у вас есть autoupdate statistics и отдельные БД не высоконагруженные (а ваши настройки в целом не высоконагруженные БД), то что вы обновляете, зачем и в каком режиме?
- Про "очистку БД от “старых” данных" у меня 2 вопроса. Первый — это что вы в данные клиента вот так лезете прям в рамках облачного администрирования? Второй — а почему не писать запросы так, чтобы данные можно было и за 10 лет хранить? Не сваливайтесь в сканы и делов-то.
- Резервное копирование: Как вы уходите от деградации произвдительности во время резервного копирования? Какую модель реально и почему используете? Как в эту модель ложатся RPO/RTO? Как обеспечивается хранение копий (хотя бы в скольки экземплярах и где)? И, да, как написано в этой статье
Резервное копирование — это последний рубеж обеспечения сохранности системы. Если администратору базы данных приходится восстанавливать продуктовую систему из резервных копий, значит, с большой вероятностью было допущено множество грубых ошибок.
- Выполняем регулярное тестовое восстановление бэкапов БД. Ок. И как вы планируете реагировать, если резервная копия битая?
- Почему в одной статье вы одновременно используете и Database mirroring и AlwaysOn AAG? Как вы между ними выбор делаете?
- Как вы используете Log shipping в облачной БД? Вы что клиенту прямо файловые ресурсы отдаёте?
- Кластеры — как используете? Есть ли дизастероустойчивость (если ЦОД дохнет весь), обеспечивается ли при этом RPO/RTO и какие? Если такие кластера есть, то как живете с задержками журналов между ЦОДами и какие они у вас в абсолютных цифрах.
- Осуществляем постоянный мониторинг состояния сервера. Всё тот же вопрос. Какие именно показатели, какие именно счетчики собираете и как трактуете? Особенно в ситуации "много потребителей, много ресурсов".
В статье не отражено:
- Проверка настроек или настройки безопасности. Банально: xp_cmdshell запрещен, OLE запрещен, CLR запрещен? Логины AD или SQL (в обоих случаях еще куча вопросов)?
- Используете ли именованные экземпляры? Как делаете чтобы они не влияли друг на друга? Настраиваете ли у них affinity или еще как? Доступен ли сервису Lock pages in memory и почему (есть и за и против).
- Используете ли штатный Resource Governor? С какими настройками? Как вообще клиентов по нагрузке разводите? Особенно в динамике, и по дискам и по памяти и по блокировкам/латчам?
- Если испольуете "свежие" версии SQL, то как быть с БД старых уровней совместимости?
- Безопасность в смысле "чтобы клиенты друг друга не видели" — как обеспечить?
- SSAS, SSRS предоставляете? Как рулите?
- Как у вас реально HADR сделан на 99,95%?
- Какие инструменты есть у клиента, чтобы диагностировать нагрузку? Может ли он хотя бы посмотреть "кто сейчас к моей БД подключен"? И как вы ему это дали не давая View server state? Какие dmv он может смотреть, а какие фигушки?
- Какой опыт настроек позаимствовали от Azure, а в чем отличаетесь и почему надо идти к вам, а не в Azure?
- Настраиваете ли вы Delayed Transaction Durability горячим промежуточным БД?
- Есть ли политика хранения BLOBов в БД? Даёте ли FileStream на них? Как живёте с этим?
Я выдохся. Вопросы еще есть, а статья ни о чем.
Благодарю за труд, интересно :)
Daar, большое спасибо! будем стараться и дальше. В следующем материале планируем максимально детально разложить услугу «Облачная база данных».
Да я честно говоря спасибо сказал speshuric, он много правильного озвучил, и о котором я даже и не задумывался :) А так с ним согласен, что как-то все поверхностно, по «вершкам» пробежались и все. Статья больше для какого-то журнала типа ЦОД или подобных, а на Хабре ожидаются какие-то тесты, сравнения, решения на крови.
speshuric, рекомендуемые нами настройки как для «облачных», так и для «не-облачных» баз обычно совпадают (применительно к MS SQL Server), исключения могут составлять сервисы вида AWS RDS, где очень урезаны возможности конечного пользователя относительно настроек SQL сервера. В статье мы рассказали не только о том, как мы инсталлируем SQL server, но и как оптимально его настраиваем и поддерживаем в соответствии с потребностями заказчика.
Нашей целью было коротко пройтись по «узким местам» настройки SQL Server и указать на наиболее оптимальные настройки и механизмы обеспечения производительности. Если начать писать о том, как все настраивать, то объем статьи легко вырастет до “SQL Server Books Online". Кроме того, для основной части настроек существуют только общие рекомендации, причем зачастую нет официальных данных от Microsoft, и для каждого конкретного случая надо принимать свои решения.
Нам кажется, что имеет смысл написать отдельные статьи на очень многие вопросы, которые вы затронули. Что скажете?
Нашей целью было коротко пройтись по «узким местам» настройки SQL Server и указать на наиболее оптимальные настройки и механизмы обеспечения производительности. Если начать писать о том, как все настраивать, то объем статьи легко вырастет до “SQL Server Books Online". Кроме того, для основной части настроек существуют только общие рекомендации, причем зачастую нет официальных данных от Microsoft, и для каждого конкретного случая надо принимать свои решения.
Нам кажется, что имеет смысл написать отдельные статьи на очень многие вопросы, которые вы затронули. Что скажете?
Позволю себе не согласиться с "рекомендуемые нами настройки" и "В статье мы рассказали". Я, собственно, и удивлён, что в статье нет почти ни одной рекомендации о конкретных настройках. Сплошные "надо настроить параметр такой-то", а как его настраивать — не скажем. По ссылкам тоже в основном "чтобы настроить параметр X выполните команду ALTER X Y, где Y новое значение".
В интернете полно рекомендаций, как настраивать standalone БД. Есть получше, есть похуже, но полно. Не надо делать еще одну статью об этом (или надо, но не этого уровня).
Вы назвали статью "Как обеспечить производительность баз данных Microsoft SQL Server, размещаемых в облаке". Я прочитал вкратце на вашем сайте, что вы под этим имеете в виду (а это не так однозначно): под облачной БД вы подразумеваете ВМ с развернутыми службами MS SQL Server на котором развернута БД (например так описано тут) и фактически вы являетесь администраторами/DBA для этой ВМ. То есть сразу видно, что вопросы взаимного влияния баз решаются не внутри инстанса SQL Server, а разведением ВМ. Не самая худшая стратегия, хотя большинство гипервизоров достаточно уныло разделяют IO нагрузку. Но вопрос остаётся актуальным "Как обеспечить производительность баз данных Microsoft SQL Server, размещаемых в облаке"?
Как настроить обычную БД понятно, а какие отличия в настройках виртуализованных больших ферм с БД?
Как вы делите диски (с учетом того, что они вирутальные)?
Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат "Отказоустойчивая база данных", "База данных повышенной доступности", "Кластерное решение"?
Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту? Такая табличка будет ценнее всей статьи.
Я не зря ссылку на h14621 кидал в комментарии. Мне очень нравятся технические white-papers от EMC именно как образец того, что нужно учесть при планировании БД. Кроме общего у них еще куча white-papers "частных случаев" есть, мне лень искать более подходящий, но там прям кладезь знаний. Есть ли у вас что-то что можно добавить хотя бы к этому документу? Если есть — это очень интересно и важно. Пусть это и будет не "быстро и коротко", а "глубоко по одному аспекту".
speshuric, прежде чем ответить, хотим вас поблагодарить (кажется, мы этого еще не делали) за то, что потратили столько времени на анализ нашего поста и вообще на нас. Это очень полезная для нас критика и важное внимание. Мы постарались ответить на основные, на наш взгляд, поставленные вами вопросы.
Как вы делите диски (с учетом того, что они виртуальные)?
Ограничиваем производительность дисков, управляя SLA на уровне СХД.
Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Нет, не используем. Для баз данных наших заказчиков мы используем производительную систему хранения данных Dell SC9000 c полками Dell SC420 на SSD дисках.
Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Бекапы хранятся на выделенной СХД. Базы данных и логи баз данных хранятся на другой выделенной СХД.
Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат «Отказоустойчивая база данных», «База данных повышенной доступности», «Кластерное решение»?
Ответим на примере MS SQL
Отказоустойчивая база данных
Предоставляется одна система с необходимыми характеристиками. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
База данных повышенной доступности (Always On Availability Groups)
Предоставляется две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй располагается резервный. В случае выхода из строя основной базы данных происходит переключение на резервную базу данных. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
Гео-кластерное решение (Failover Clustering и Always On Availability Groups). Данная опция в разработке. Плановый срок ноябрь 2017г.
Предоставляется три выделенных системы с необходимыми характеристиками. Две машины объединяются в кластер и обслуживают работу с основной базой данных. Третья машина работает с резервной базой данных. В случае выхода из строя одного из узлов кластера, сервис поднимается на втором узле. В случае выхода из строя основной базы данных происходит переключение на резервную. Сервис остаётся доступным в случае выхода из строя любого из трёх хостов. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час).
Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
Для не misson-critical БД — нет, не используем. Нет, БД не страдает. Для mission-critical БД – да, используем. При этом обязательно выставляем соответствующий параметр max SQL server memory (как и для не mission-critical баз) и, соответственно, настраиваем гипервизор, чтобы не страдал :).
Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Для расчета доступности сервиса используются данные системы мониторинга, контролирующей доступность каждого из нижеприведенных компонентов сервиса: хоста, базы данных, процессов прослушивания (Listener).
Поэтому, да, если инстанс пингуется, то это доступность сервиса.
При приходе нового заказчика мы выясняем его бизнес процессы, окна простоя и деградации производительности и настраиваем планы обслуживания в соответствии с бизнес ожиданиями заказчика.
Естественно никто не будет ребилдить индексы бездумно. У нас есть пример ребилда 2 терабайтных индексов, и на это отводится время раз в месяц в соответствии с договоренностями с бизнес подразделениями Заказчика.
Если же клиент ощутит нехватку производительности при плановых работах, то заводится инцидент и по нему начинается анализ.
Если выяснится, что влияет именно DBCC CHECKDB, то возможны варианты развития событий, например, вынести CHECKDB на вторичную реплику в AAG; вынести CHECKDB на систему восстановленную из бекапа, делать CHECKDB не регулярно.
Мы как DBA предлагаем наиболее приемлемый вариант из Best practices с описанием всех достоинств и недостатков, а клиент выбирает подходящий ему вариант.
У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту?
*Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок – возможно увеличение.
** Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок при использовании SQL server 2016 – возможно увеличение.
Как вы делите диски (с учетом того, что они виртуальные)?
Ограничиваем производительность дисков, управляя SLA на уровне СХД.
Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Нет, не используем. Для баз данных наших заказчиков мы используем производительную систему хранения данных Dell SC9000 c полками Dell SC420 на SSD дисках.
Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Бекапы хранятся на выделенной СХД. Базы данных и логи баз данных хранятся на другой выделенной СХД.
Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат «Отказоустойчивая база данных», «База данных повышенной доступности», «Кластерное решение»?
Ответим на примере MS SQL
Отказоустойчивая база данных
Предоставляется одна система с необходимыми характеристиками. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
База данных повышенной доступности (Always On Availability Groups)
Предоставляется две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй располагается резервный. В случае выхода из строя основной базы данных происходит переключение на резервную базу данных. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
Гео-кластерное решение (Failover Clustering и Always On Availability Groups). Данная опция в разработке. Плановый срок ноябрь 2017г.
Предоставляется три выделенных системы с необходимыми характеристиками. Две машины объединяются в кластер и обслуживают работу с основной базой данных. Третья машина работает с резервной базой данных. В случае выхода из строя одного из узлов кластера, сервис поднимается на втором узле. В случае выхода из строя основной базы данных происходит переключение на резервную. Сервис остаётся доступным в случае выхода из строя любого из трёх хостов. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час).
Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
Для не misson-critical БД — нет, не используем. Нет, БД не страдает. Для mission-critical БД – да, используем. При этом обязательно выставляем соответствующий параметр max SQL server memory (как и для не mission-critical баз) и, соответственно, настраиваем гипервизор, чтобы не страдал :).
Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Для расчета доступности сервиса используются данные системы мониторинга, контролирующей доступность каждого из нижеприведенных компонентов сервиса: хоста, базы данных, процессов прослушивания (Listener).
Поэтому, да, если инстанс пингуется, то это доступность сервиса.
При приходе нового заказчика мы выясняем его бизнес процессы, окна простоя и деградации производительности и настраиваем планы обслуживания в соответствии с бизнес ожиданиями заказчика.
Естественно никто не будет ребилдить индексы бездумно. У нас есть пример ребилда 2 терабайтных индексов, и на это отводится время раз в месяц в соответствии с договоренностями с бизнес подразделениями Заказчика.
Если же клиент ощутит нехватку производительности при плановых работах, то заводится инцидент и по нему начинается анализ.
Если выяснится, что влияет именно DBCC CHECKDB, то возможны варианты развития событий, например, вынести CHECKDB на вторичную реплику в AAG; вынести CHECKDB на систему восстановленную из бекапа, делать CHECKDB не регулярно.
Мы как DBA предлагаем наиболее приемлемый вариант из Best practices с описанием всех достоинств и недостатков, а клиент выбирает подходящий ему вариант.
У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту?
*Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок – возможно увеличение.
** Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок при использовании SQL server 2016 – возможно увеличение.
О! Спасибо за прекрасный комментарий по существу. Этот комментарий, кажется, в несколько раз информативнее и лучше статьи :) Спасибо, что поделились опытом.
На самом деле описанные решения разумные и обоснованные и абстрактную средненькую БД хостить с таким подходом не страшно. Только max server memory какой-то странный, но, я думаю, это опечатка и это параметр для RAM в ГБ указанного в поле количество CPU: странно выделять 29 ГБ из 512 на СУБД.
На самом деле описанные решения разумные и обоснованные и абстрактную средненькую БД хостить с таким подходом не страшно. Только max server memory какой-то странный, но, я думаю, это опечатка и это параметр для RAM в ГБ указанного в поле количество CPU: странно выделять 29 ГБ из 512 на СУБД.
Sign up to leave a comment.
Как обеспечить производительность баз данных Microsoft SQL Server, размещаемых в облаке