Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Как правильно распределить диски и файлы БД на них  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Maxx
не говоря о том,что сами данные на диск сразу напрямую вообще в случае с мсскл писаться не будут

А как же commit transaction?
13 авг 13, 15:35    [14703023]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Гость333
commit transaction?

Да сие вообщем внутрення операция сиквела,которая никак не говорит о том,что данные записанны на жесткий диск сервера физически.
13 авг 13, 15:37    [14703041]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Maxx,
Я все переустановлю с нуля. Разобью 10 дисков на 6+4 в 10 райдах.
И последую вашим рекомендациям.
Осталось только купить NAS:)
13 авг 13, 15:52    [14703133]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
OYM
Осталось только купить NAS:)

а чем вас простой HBA не устроил то ?
13 авг 13, 15:55    [14703149]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Гость333
Maxx
не говоря о том,что сами данные на диск сразу напрямую вообще в случае с мсскл писаться не будут

А как же commit transaction?


Это просто запись в журнале, о том, что страницы в памяти изменены. В случае сбоя сервера и его последующего старта, сервер не откатит транзакции у которого есть пометка о commite
13 авг 13, 15:59    [14703181]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Maxx
OYM
Осталось только купить NAS:)

а чем вас простой HBA не устроил то ?

У меня кстати есть 2 свободных слота для дисков. Всего 12, использую 10. Как вариант докупить 2 SAS без райда! и на оба скидывать копии.
13 авг 13, 16:05    [14703224]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
OYM,

тоже правильно..толькоб я все равно еще копировал бы куда нить бекап отдельно
13 авг 13, 16:07    [14703239]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Maxx
OYM,

тоже правильно..толькоб я все равно еще копировал бы куда нить бекап отдельно

Ну правильно потом по сети в другую серверную, другого города
13 авг 13, 16:14    [14703291]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Гость333
Member

Откуда:
Сообщений: 3683
OYM
Гость333
пропущено...

А как же commit transaction?


Это просто запись в журнале, о том, что страницы в памяти изменены. В случае сбоя сервера и его последующего старта, сервер не откатит транзакции у которого есть пометка о commite

Ничего не понял, при чём тут изменённые страницы в памяти?

Я имел в виду, что commit transaction — это синхронная операция, которая считается выполненной, когда от операционной системы поступает сообщение, что некая часть буферного пула, относящегося к логу транзакций, физически записана на диск.

Другое дело, что контроллер RAID может "обманывать" ОС, сообщая о завершении записи, хотя часть данных ещё находится в кэше контроллера.
13 авг 13, 16:21    [14703342]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Гость333
OYM
пропущено...


Это просто запись в журнале, о том, что страницы в памяти изменены. В случае сбоя сервера и его последующего старта, сервер не откатит транзакции у которого есть пометка о commite

Ничего не понял, при чём тут изменённые страницы в памяти?

Я имел в виду, что commit transaction — это синхронная операция, которая считается выполненной, когда от операционной системы поступает сообщение, что некая часть буферного пула, относящегося к логу транзакций, физически записана на диск.

Другое дело, что контроллер RAID может "обманывать" ОС, сообщая о завершении записи, хотя часть данных ещё находится в кэше контроллера.


логу транзакций

После commit только идет запись в лог! В файл данных запись не идет.
13 авг 13, 16:26    [14703373]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Гость333
Member

Откуда:
Сообщений: 3683
OYM
логу транзакций

После commit только идет запись в лог! В файл данных запись не идет.

А, вот оно что. В журнал транзакций данные не записываются, а записываются только отметки об изменённых страницах в памяти. Ок, буду знать.
13 авг 13, 16:36    [14703467]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
наблюдатель-переводчик
Guest
OYM,
Гость333 и не настаивал на _файле_данных_. упор делался на _диск_
он на фразу
Maxx
не говоря о том,что сами данные на диск сразу напрямую вообще в случае с мсскл писаться не будут

отреагировал. на _диск_.
а Вы реагируете на _данные_.
т.е., как я понимаю, под "данными" Гость333 имел в виду не запись в _файл_данных_,
а запись в лог-файл, что write-ahead logging означает, что на каждый _коммит_ должна идти запись на _диск_
13 авг 13, 16:44    [14703544]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Гость333
Member

Откуда:
Сообщений: 3683
наблюдатель-переводчик,

Спасибо за перевод, я подозревал, что здесь между нами чисто терминологическое недопонимание :)
13 авг 13, 16:55    [14703622]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Отсюда взято ,довольно подробно
+
1.клиент посылает серверу команду модификации данных (тот же UPDATE, для определенности; так же допустим, что фильтр WHERE указанной команды предписывает ей изменить значение ровно одной ячейки в ровно одной строке таблицы).
2.страница данных содержащая целевую ячейку загружается в специальную область памяти сервера называемую буферным пулом (buffer pool), а более точно — в тот «отсек» указанного пула, который некоторые называют буферным кэшем (buffer cache), а некоторые называют его же кэшем данных (data cache). Это, кстати, снова к вопросу «как правильно говорить по-русски, а равно по-английски»? Очень просто — говорите так, что бы вас понимали... Так вот, на этом этапе нужная страница оказывается в RAM и обязательно в RAM. Разумеется, если в силу любых причин нужная страница к началу данного шага уже находится в RAM, то шаг просто пропускается. Зачем нам (и SQL Server-у тоже) лишний раз попусту дергать HDD, верно?
3.если клиент не предварил команду UPDATE транзакцией явной, то сервер делает это за него. Иными словами сервер исполняет команду BEGIN TRAN, «нравится» это клиенту или нет. Многие знают, что сама команда BEGIN TRAN помечается в логе персональной записью, а именно как операция LOP_BEGIN_XACT в терминах одной из недокументированных «фич» SQL сервера — команды DBCC LOG (она более чем подробно рассматривается далее). И это верно. Но совсем немногие знают, что эта самая запись вносится в лог не в текущем шаге. А чуть погодя. До текущего момента (включая и его самого) лог не изменился ни на йоту, если, конечно, его не изменила транзакция иного клиента. Для простоты можно положить, что у нас в принципе система доступна лишь с единственного рабочего места, а значит любые конкурентные транзакции исключены, и с таким допущением мы можем утверждать, что пока лог гарантированно не менялся.
4.дабы обеспечить транзакционную целостность предстоящих модификаций движок накладывает необходимые блокировки (locks). Данная тема (блокировки и их влияние на ход транзакций) лежит совершенно за границами изучаемого вами в настоящий момент материала, а поэтому автор будет предельно краток — необходимые блокировки будут иметь место. Для нашего вопроса самого этого факта достаточно.
5.целевая ячейка изменяется в памяти и только в памяти (в том самом buffer или data cache). Никакое «прямое редактирование» содержимого ячейки на диске невозможно. Иными словами, в течении всего описываемого процесса (за исключением его последнего шага) файлы данных (.mdf/.ndf) принципиально не могут измениться.
6.страница в буферном кэше немедленно помечается как «грязная» (dirty). Ее же версия на диске никак особо не помечается. Пометка версии в кэше обусловлена необходимостью создать такое окружение, в котором операция CHECKPOINT (см. далее) выполнится правильно, а, главное, максимально эффективно. Версия страницы на диске не нуждается ни в каких пометках, если ей суждено быть затертой новой информацией (той самой страницей из RAM) — так и будет, никакие пометки помочь/воспрепятствовать этому не могут.
7.информация о проведенных изменениях вносится в лог файл. Причем на этом шаге вносится сразу две записи: операция LOP_BEGIN_XACT (да, только сейчас!) и сразу же операция LOP_MODIFY_ROW. Но вот они меняют именно файл лога, т.е. .ldf, и такие изменения происходят практически в синхронном режиме.
8.сервер исполняет команду COMMIT TRAN, опять же, «с подачи» клиента или без таковой. Такая команда снова имеет персональную запись в .ldf файле (которая незамедлительно и добавляется к последнему), и проходит там как операция LOP_COMMIT_XACT в терминах команды DBCC LOG. Разумеется, тут вполне может оказаться и альтернатива — ROLLBACK TRAN, а в лог добавится, соответственно, операция LOP_ABORT_XACT. Однако мы примем первый вариант — клиент именно фиксирует (commit) произведенные изменения, а с «ролбэком» у нас разговор отдельный будет.
9.движок сервера проверяет, что все операции подлежащие внесению в лог-файл, включая и финальные LOP_COMMIT_XACT/LOP_ABORT_XACT успешно внесены именно в .ldf-файл, т.е. на диск.
10.и лишь после этого упомянутые в шаге 4-м блокировки снимаются, а клиент получает уведомление об успешности запрошенной им транзакции.
11.некоторое время (и в отдельных случаях довольно продолжительное) измененная страница данных будет существовать в двух «версиях»: «версии диска» (.mdf/.ndf файл) и «RAM версии» (та самая dirty page). Это потому, что движок сервера вовсе не бросается со всех ног записывать первую же замеченную им «грязную» страницу на диск, а накапливает их некоторый объем, дабы впоследствии провести синхронизацию упомянутых версий для всех накопившихся страниц «одним движением». Понятно что направление такой синхронизации всегда и только RAM → диск и никогда обратно, т.к. диск ни в какой момент времени не содержит версию данных более новую или более «правильную».
12.это самое «движение» имеет название контрольной точки, она же CHECKPOINT. Суть этой команды (а это, помимо всего, и инструкция языка T-SQL) очень проста — измененные (они же «грязные») страницы данных записываются из буферного кэша текущей базы данных на диск. Дальнейшие наши исследования неопровержимо покажут, что в предыдущем предложении после определения «очень проста» обязано следовать уточнение «как кажется на первый взгляд». Однако на текущий момент будем считать что действительно ничего «такого» в чек-поинте нет, ну сбросились «грязные» страницы на диск и сбросились. И — да, как и было сказано в шаге 5-м, файлы данных меняются лишь сейчас и только сейчас. Предыдущие шаги могут максимум считать их информацию, но ни в коем случае не изменить ее.
13 авг 13, 17:00    [14703672]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
наблюдатель-переводчик
Guest
Maxx,

я думаю, мы все давно ознакомились с блогом уважаемого SamMan-а.
противоречия между вами тремя никакого нет.
OYM упирал на то, что "данные" еще долго на диск не попадут,
а Гость333 настаивал, что еще как попадут, сразу по коммиту, ведь данные не только в .mdf идут,
а еще как в .ldf (именно данные, а не только "отметка о коммите")
а Вы вроде просто на кэше настаивали, не?
что "на диск-то оно на диск, но вообще-то в кэш попадет"
вроде же все теперь друг друга поняли, разве нет?
13 авг 13, 17:19    [14703809]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
Maxx
Отсюда взято ,довольно подробно
+
1.клиент посылает серверу команду модификации данных (тот же UPDATE, для определенности; так же допустим, что фильтр WHERE указанной команды предписывает ей изменить значение ровно одной ячейки в ровно одной строке таблицы).
2.страница данных содержащая целевую ячейку загружается в специальную область памяти сервера называемую буферным пулом (buffer pool), а более точно — в тот «отсек» указанного пула, который некоторые называют буферным кэшем (buffer cache), а некоторые называют его же кэшем данных (data cache). Это, кстати, снова к вопросу «как правильно говорить по-русски, а равно по-английски»? Очень просто — говорите так, что бы вас понимали... Так вот, на этом этапе нужная страница оказывается в RAM и обязательно в RAM. Разумеется, если в силу любых причин нужная страница к началу данного шага уже находится в RAM, то шаг просто пропускается. Зачем нам (и SQL Server-у тоже) лишний раз попусту дергать HDD, верно?
3.если клиент не предварил команду UPDATE транзакцией явной, то сервер делает это за него. Иными словами сервер исполняет команду BEGIN TRAN, «нравится» это клиенту или нет. Многие знают, что сама команда BEGIN TRAN помечается в логе персональной записью, а именно как операция LOP_BEGIN_XACT в терминах одной из недокументированных «фич» SQL сервера — команды DBCC LOG (она более чем подробно рассматривается далее). И это верно. Но совсем немногие знают, что эта самая запись вносится в лог не в текущем шаге. А чуть погодя. До текущего момента (включая и его самого) лог не изменился ни на йоту, если, конечно, его не изменила транзакция иного клиента. Для простоты можно положить, что у нас в принципе система доступна лишь с единственного рабочего места, а значит любые конкурентные транзакции исключены, и с таким допущением мы можем утверждать, что пока лог гарантированно не менялся.
4.дабы обеспечить транзакционную целостность предстоящих модификаций движок накладывает необходимые блокировки (locks). Данная тема (блокировки и их влияние на ход транзакций) лежит совершенно за границами изучаемого вами в настоящий момент материала, а поэтому автор будет предельно краток — необходимые блокировки будут иметь место. Для нашего вопроса самого этого факта достаточно.
5.целевая ячейка изменяется в памяти и только в памяти (в том самом buffer или data cache). Никакое «прямое редактирование» содержимого ячейки на диске невозможно. Иными словами, в течении всего описываемого процесса (за исключением его последнего шага) файлы данных (.mdf/.ndf) принципиально не могут измениться.
6.страница в буферном кэше немедленно помечается как «грязная» (dirty). Ее же версия на диске никак особо не помечается. Пометка версии в кэше обусловлена необходимостью создать такое окружение, в котором операция CHECKPOINT (см. далее) выполнится правильно, а, главное, максимально эффективно. Версия страницы на диске не нуждается ни в каких пометках, если ей суждено быть затертой новой информацией (той самой страницей из RAM) — так и будет, никакие пометки помочь/воспрепятствовать этому не могут.
7.информация о проведенных изменениях вносится в лог файл. Причем на этом шаге вносится сразу две записи: операция LOP_BEGIN_XACT (да, только сейчас!) и сразу же операция LOP_MODIFY_ROW. Но вот они меняют именно файл лога, т.е. .ldf, и такие изменения происходят практически в синхронном режиме.
8.сервер исполняет команду COMMIT TRAN, опять же, «с подачи» клиента или без таковой. Такая команда снова имеет персональную запись в .ldf файле (которая незамедлительно и добавляется к последнему), и проходит там как операция LOP_COMMIT_XACT в терминах команды DBCC LOG. Разумеется, тут вполне может оказаться и альтернатива — ROLLBACK TRAN, а в лог добавится, соответственно, операция LOP_ABORT_XACT. Однако мы примем первый вариант — клиент именно фиксирует (commit) произведенные изменения, а с «ролбэком» у нас разговор отдельный будет.
9.движок сервера проверяет, что все операции подлежащие внесению в лог-файл, включая и финальные LOP_COMMIT_XACT/LOP_ABORT_XACT успешно внесены именно в .ldf-файл, т.е. на диск.
10.и лишь после этого упомянутые в шаге 4-м блокировки снимаются, а клиент получает уведомление об успешности запрошенной им транзакции.
11.некоторое время (и в отдельных случаях довольно продолжительное) измененная страница данных будет существовать в двух «версиях»: «версии диска» (.mdf/.ndf файл) и «RAM версии» (та самая dirty page). Это потому, что движок сервера вовсе не бросается со всех ног записывать первую же замеченную им «грязную» страницу на диск, а накапливает их некоторый объем, дабы впоследствии провести синхронизацию упомянутых версий для всех накопившихся страниц «одним движением». Понятно что направление такой синхронизации всегда и только RAM → диск и никогда обратно, т.к. диск ни в какой момент времени не содержит версию данных более новую или более «правильную».
12.это самое «движение» имеет название контрольной точки, она же CHECKPOINT. Суть этой команды (а это, помимо всего, и инструкция языка T-SQL) очень проста — измененные (они же «грязные») страницы данных записываются из буферного кэша текущей базы данных на диск. Дальнейшие наши исследования неопровержимо покажут, что в предыдущем предложении после определения «очень проста» обязано следовать уточнение «как кажется на первый взгляд». Однако на текущий момент будем считать что действительно ничего «такого» в чек-поинте нет, ну сбросились «грязные» страницы на диск и сбросились. И — да, как и было сказано в шаге 5-м, файлы данных меняются лишь сейчас и только сейчас. Предыдущие шаги могут максимум считать их информацию, но ни в коем случае не изменить ее.


Интересно, а как будет себя вести сервер в "версионном" механизме?
13 авг 13, 17:24    [14703840]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
наблюдатель-переводчик - да не вапрос ,все друг друга поняли,и сие здорово
13 авг 13, 17:24    [14703841]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
баба клава
Guest
OYM
Скажите, а могу я на второй "журнальный райд" делать резервные копии базы и журналов.


Не, для того этим баринам отдельный рейд и выделяют. В основном туда интенсивная запись будет производиться.

Crazy_Driver
Все в RAID 10 и не издеваться над сервером.


плюсану этого господина, если контроллер один.
13 авг 13, 22:55    [14704920]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
OYM
У меня кстати есть 2 свободных слота для дисков. Всего 12, использую 10. Как вариант докупить 2 SAS без райда! и на оба скидывать копии.
А вот это лучше пустить на "горячую замену".
Для резервных копий купите файберченаловскую карточку, прицепитесь к какой-нить полке и копируйте наздоровье.

Сообщение было отредактировано: 14 авг 13, 06:38
14 авг 13, 06:37    [14705643]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
edyaN
Member

Откуда:
Сообщений: 185
почему все так любят RAID10? Чем в данном случае плоха конфигурация с пятью RAID1?
1- под систему
2- под логи
а на оставшихся трех разместить файлы данных.
Ведь MS заявляет, что SQLServer лучше балансирует нагрузку между дисками, чем raid-системы.
14 авг 13, 10:40    [14706263]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
edyaN
почему все так любят RAID10? Чем в данном случае плоха конфигурация с пятью RAID1?
1- под систему
2- под логи
а на оставшихся трех разместить файлы данных.
Ведь MS заявляет, что SQLServer лучше балансирует нагрузку между дисками, чем raid-системы.
Всё правильно, но такой конфигурацией сложнее управлять. Много дисков, файлов - просто менее удобно.

Кроме того, MSSQL не умеет распределять нагрузку на несколько файлов лога, так что если пары дисков в зеркале недостаточно, то без вариантов нужен RAID
14 авг 13, 11:00    [14706372]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
баба клава
Crazy_Driver
Все в RAID 10 и не издеваться над сервером.

плюсану этого господина, если контроллер один.
А почему "не издеваться"? Чем это будет плохо для производительности?

Я ещё понимаю - "не заморачиваться" - так можно сказать. Современный хороший контроллер может обеспечить не худшую производительность без разбиения, но лучше то она точно не будет.
14 авг 13, 11:02    [14706392]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
OYM
Member

Откуда:
Сообщений: 236
alexeyvg
edyaN
почему все так любят RAID10? Чем в данном случае плоха конфигурация с пятью RAID1?
1- под систему
2- под логи
а на оставшихся трех разместить файлы данных.
Ведь MS заявляет, что SQLServer лучше балансирует нагрузку между дисками, чем raid-системы.
Всё правильно, но такой конфигурацией сложнее управлять. Много дисков, файлов - просто менее удобно.

Кроме того, MSSQL не умеет распределять нагрузку на несколько файлов лога, так что если пары дисков в зеркале недостаточно, то без вариантов нужен RAID


А зачем делать несколько файлов лога?
14 авг 13, 11:06    [14706426]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
OYM
alexeyvg
пропущено...
Всё правильно, но такой конфигурацией сложнее управлять. Много дисков, файлов - просто менее удобно.

Кроме того, MSSQL не умеет распределять нагрузку на несколько файлов лога, так что если пары дисков в зеркале недостаточно, то без вариантов нужен RAID


А зачем делать несколько файлов лога?
Это касается предложения edyaN, которое я комментирую.

Невозможно распределить нагрузку на лог транзакций на несколько зеркал средствами MSSQL, он это не умеет. Только средствами контроллера или Windows (кстати, второй вариант может быть эффективнее и никогда не будет хуже).
14 авг 13, 11:34    [14706581]     Ответить | Цитировать Сообщить модератору
 Re: Как правильно распределить диски и файлы БД на них  [new]
edyaN
Member

Откуда:
Сообщений: 185
ну я вообще-то не много файлов для лога транзакций имел ввиду, а много файлов для данных.
14 авг 13, 11:43    [14706646]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить