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

Откуда: Харьков
Сообщений: 600
Господа,

хотим использовать Database Snapshots (не путать со snapshot isolation level !) для того, чтобы периодически выгружать данные с помощью bcp . У кого есть реальный опыт работы с этой штукой? Насколько возрастает нагрузка на сервер? Какие могут быть подводные камни?

МСДН почитал. Хотелось бы историй из реальной жизни.

Наша база - порядка 1.5+Т, достаточно много инсёртов, порядка 50к-строк\час апдейтов. bcp по длительности ожидается порядка часа-полтора.
30 янв 12, 17:25    [11998249]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
mwolf
Database Snapshots
база - порядка 1.5+Т, достаточно много инсёртов, порядка 50к-строк\час апдейтов
Up.

Как я понимаю, это происходит на уровне файловой системы.
Если страница меняется, то тупо записывается в другое место (фрагментация). Файл снапа продолжает смотреть на старый блок памяти.
Т.е. снапы практически не создают никакой нагрузки. Но это теория.
31 янв 12, 19:33    [12007008]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Slava_Nik
Member

Откуда: из России
Сообщений: 888
Mnior
mwolf
Database Snapshots
база - порядка 1.5+Т, достаточно много инсёртов, порядка 50к-строк\час апдейтов
Up.

Как я понимаю, это происходит на уровне файловой системы.
Если страница меняется, то тупо записывается в другое место (фрагментация). Файл снапа продолжает смотреть на старый блок памяти.
Т.е. снапы практически не создают никакой нагрузки. Но это теория.

что создает дисковую нагрузку.
эти страницы изменненые 50 к\час - строк будут копироваться в другое место.
а с резервного сервера нельзя выгружать? или нужны данные на конкретный период времени?
хотя можно сделать так , если перед bcp создать снепшот, прогнать bcp, удалить снепшот, попробовать можно , но надо буть уверенным в дисковой системе.
31 янв 12, 23:41    [12008125]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Crimean
Member

Откуда:
Сообщений: 13148
а ради чего это все? в чем поможет снапшот? ну который не уровень изоляции, конечно. и почему бы не использовать тот, который как раз уровень изоляции, к примеру?
31 янв 12, 23:44    [12008146]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
mwolf
Member

Откуда: Харьков
Сообщений: 600
Slava_Nik
хотя можно сделать так , если перед bcp создать снепшот, прогнать bcp, удалить снепшот, попробовать можно , но надо буть уверенным в дисковой системе.


Так и собирались.))
А что с дисковой системой? Потому что, как раз и хотелось бы знать насколько тяжело всё получается
1 фев 12, 17:41    [12014025]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
mwolf
Member

Откуда: Харьков
Сообщений: 600
Crimean
и почему бы не использовать тот, который как раз уровень изоляции, к примеру?

Для реализации уровеня изоляции снепшот ВСЕ данные нужные для создания снепшота загоняются в ТемпДБ, в итоге выгрузка таблицы с парой миллиардов записей укладывает систему.

Crimean
в чем поможет снапшот? ну который не уровень изоляции, конечно.

Снепшот, который не уровень изоляции, данные хранит в файлах, к тому же хранит только нужные страницы, а не всю таблицу. И поэтому МС уверяет, что дисковых операций будет не сильно много. Но хотелось бы подробностей перед тем как предлагать это заказчику.

Crimean
а ради чего это все?

Нужно это всё чтобы выгрузить большое количество данных (до 10 млрд записей на таблицу) не залочив их при этом и желательно в согласованном виде. Сейчас во избежание локов выгрузка идёт через дёрти рид, в итоге такого мусора в данных наловили, что ужас :-(
1 фев 12, 17:53    [12014168]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Crimean
Member

Откуда:
Сообщений: 13148
> Для реализации уровеня изоляции снепшот ВСЕ данные нужные для создания снепшота загоняются в ТемпДБ

да ну! по-моему оно вовсе не так работает. тоже "запасает" только измененные страницы

> желательно в согласованном виде

а вот это - аргумент + bcp ибо использовать уровень изоляции будет тупо сложно технически, если выгружать кучу объектов
в любом случае деваться вам, похоже, особо некуда :)
1 фев 12, 17:59    [12014260]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
любитель снапшотов
Guest
Crimean
а ради чего это все? в чем поможет снапшот? ну который не уровень изоляции, конечно. и почему бы не использовать тот, который как раз уровень изоляции, к примеру?
По идее, снапшот будет полегче, чем уровень изоляции снапшот. При том снапшоте, что уровень изоляции, будет и дисковая нагрузка на шпинделя с tempdb и оверхед на поддержание цепочек версий. И дискам с tempdb придется никак не легче, чем дискам с файловым снапшотом. А при снапшоте что у ТСа, положат файлик куда нибудь и вся нагрузка будет только на копирование туда изменённых страниц.
2 TC. Мы пользуем снапшоты. Базы по 200-500Гб, OLTP, больше одного снапшота не создавали, создание в утреннее время, нагрузка невысокая. Время существование снапшота менее часа. Жалоб нет. Цифр сравнительных измерений тоже.
1 фев 12, 18:08    [12014373]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
любитель снапшотов
Guest
Mnior
mwolf
Database Snapshots
база - порядка 1.5+Т, достаточно много инсёртов, порядка 50к-строк\час апдейтов
Up.

Как я понимаю, это происходит на уровне файловой системы.
Если страница меняется, то тупо записывается в другое место (фрагментация). Файл снапа продолжает смотреть на старый блок памяти.
Т.е. снапы практически не создают никакой нагрузки. Но это теория.
Как я понимаю, все не совсем так. Если страница меняется, то старая страница копируется в файл снапшота, а обновление на странице либо пишется в те же 8Кб, где была старая страница (что к фрагментации не приведёт) либо, если новых данных больше, чем может вместить старая страница происходит сплит.
Таким образом, дополнительной фрагментации для пользователей основной БД (не снапшота) не будет (все будет точно так, как если бы снапшота не было). А доп. нагрузка, которую даёт снапшот состоит в копировании старых данных в новый файл.
1 фев 12, 18:17    [12014462]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
любитель снапшотов,
Не, просто мне казалось что сервер не участвует в снапах, это делает файловая система оси. И делается в рамках одного диска.
И на уковне файловой таблицы. Т.е. эффективно.
Но в раеле, получается снапы сделаны через задницу. Вот отвлечёмся от БД. Ну накуя перемещать из А в Б, а потом писать в А. Чё нельзя сразу писать в Б. Естественно речь идёт про один физический носитель.
Ну да ладно.

Второе. Фрагментация сама по себе не сильно прям к месту, т.к. она сама по себе есть, как на уровне ФС так и на уровне файла БД.
Для SSD ваще монописуально.

Третье, А уровни изоляции к снапам не имеют никакого отношения, савсэм.

Итого. Помножаем запись на диск примерно на два, только в эксентах, а не строках.
1 фев 12, 22:27    [12015664]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
fedya.fedpet
Member

Откуда:
Сообщений: 11
Кстати а как это вообще работает - это Volume Shadow Copy что ли ? (VSS)
2 фев 12, 02:38    [12016442]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
ABC_1982
Member

Откуда: Москва
Сообщений: 418
Mnior
Но в раеле, получается снапы сделаны через задницу. Вот отвлечёмся от БД. Ну накуя перемещать из А в Б, а потом писать в А. Чё нельзя сразу писать в Б. Естественно речь идёт про один физический носитель.
Ну да ладно.

1. Чтобы удаление снапшота было максимально легким.
2. Чтобы было возможно создание нескольких снапшотов.

Достаточно для начала?
2 фев 12, 11:15    [12017477]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
ABC_1982
Mnior
Но в раеле, получается снапы сделаны через задницу. Вот отвлечёмся от БД. Ну накуя перемещать из А в Б, а потом писать в А. Чё нельзя сразу писать в Б. Естественно речь идёт про один физический носитель.
Ну да ладно.

1. Чтобы удаление снапшота было максимально легким.
2. Чтобы было возможно создание нескольких снапшотов.

Достаточно для начала?
Всё мимо. Никак это не влияет, и скорее даже наоборот.
Сейчас при изменении блок копируется во все снапы. Т.е. при изменении 16K для 10 снапов нужно будет освободить 160K места на дисках (хотя не факт, но по ходу). При их удаленнии надо их все освобождать.
Если было бы сделано кошерно. То нужно было только 16K места для новых данных, уменьшить счётчик у блока на 1 (11 -> 10, 11 это 1 БД + 10 снапов).
А при освобождении только одну копию очистить. Кста, секурити может требовать заполнение мусором (нулями) освободившийся блок.

Так что только две "особенности":
1. Один механизм для снапов - на разных носителей или на одном.
2. Отсутсвие фрагментации основного файла за счёт фрагментации всех её снапов.
3. Не требуется реализации на уровне ФС (но она то там есть + всё равно есть ограничения - NTFS (журналируемая ФС), транзакции то нужны).

Кароче, ж*пнуто сделано, как ни крути.
2 фев 12, 14:06    [12019008]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
ABC_1982
Member

Откуда: Москва
Сообщений: 418
Mnior
Всё мимо. Никак это не влияет, и скорее даже наоборот.
Сейчас при изменении блок копируется во все снапы. Т.е. при изменении 16K для 10 снапов нужно будет освободить 160K места на дисках (хотя не факт, но по ходу). При их удаленнии надо их все освобождать.
Если было бы сделано кошерно. То нужно было только 16K места для новых данных, уменьшить счётчик у блока на 1 (11 -> 10, 11 это 1 БД + 10 снапов).

Стоп, давай подробнее. Голова не варит. :) Я правильно понимаю?

Допустим, один снапшот сделан в 11:00, другой в 12:00, третий в 13:00...
Страница меняется трижды в час, допустим.

Сейчас для каждого снапшота потребуется по одной операции записи, итого 10*1 = 10 операций записи. Это константа и меняться не будет для данной конкретной страницы. Любое её изменение потребует однократной записи старого значения во все существующие на момент изменения снапшоты. Потребуется 80КБ места под страницу.

Если нам нужно запросить актуальные данные, расположенные на нескольких страницах - мы запрашиваем их напрямую с БД. Нужны замороженные данные в ретроспективе - запрашиваем через снапшот. В любом случае чтение будет либо через базу, либо через один снапшот и базу.

Не нужны данные в ретроспективе - удаляем снапшот, не занимаясь слиянием данных. Потеря или повреждение снапшота не затрагивает данные в базе.

В твоем "кошерном" варианте при изменении страницы мы пишем только в один крайний снапшот. Ок, нам требуется для этого 8КБ места и одна операция записи.

Но при чтении актуальных данных с нескольких страниц мы должны в худшем случае пройтись по всем снапшотам и самой базе. При чтении данных на снапшот назад мы должны пройтись по всем снапшотам, кроме крайнего и самой базе.

При удалении снапшота мы должны слить его данные со снапшотом, созданным после него. Потеря или повреждение любого снапшота означает потерю данных.
2 фев 12, 14:43    [12019465]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
ABC_1982
Допустим, один снапшот сделан в 11:00, другой в 12:00, третий в 13:00...
Фиолетово.
ABC_1982
Сейчас для каждого снапшота потребуется по одной операции записи, итого 10*1 = 10 операций записи.
+1 на изменение в БД.
ABC_1982
повреждение снапшота не затрагивает данные в базе
Если повреждается общий блок то летит всё. Независимо от указанных варантов.

ABC_1982
В твоем "кошерном" варианте при изменении страницы мы пишем только в один крайний снапшот.
Чё за бред.
При изменении данных снапы не трогаются ваапсче. И воопсче неважно есть ли снапы или их нет.
Если количество линков на блок один, до его можно переписать сверху, если нет то пишем в другой блок, а в том уменьшаем количество линков на один. А в технологии CopyOnWrite в любом случае делается запись только в новый блок, но это здесь не важно.
Снапы как смотрели на теже блоки данных так и продолжают смотреть. Они полноценно ReadOnly, а не как сейчас, меняются (физически не логически) при изменении БД.
2 фев 12, 15:04    [12019710]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
ABC_1982
Member

Откуда: Москва
Сообщений: 418
Mnior
Фиолетово.

Угу, просто исходные данные для структурирования мысли, так сказать.

Mnior
Если повреждается общий блок то летит всё. Независимо от указанных варантов.

Разумеется.

Mnior
Чё за бред.

Давай повежливей, ОК?

Mnior
При изменении данных снапы не трогаются ваапсче. И воопсче неважно есть ли снапы или их нет.
Если количество линков на блок один, до его можно переписать сверху, если нет то пишем в другой блок, а в том уменьшаем количество линков на один.

А, теперь понял какую реализацию ты имеешь в виду. Просто дословно понял это:
Mnior
перемещать из А в Б, а потом писать в А. Чё нельзя сразу писать в Б.


Но это была бы прежде всего существенная переписка движка хранения данных. Стоила бы овчинка выделки?
2 фев 12, 16:20    [12020505]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
За вежливость ссори, грубый ибо плохо чуствую ... "душевное" состояние. Зациклен на смысле.
ABC_1982
Но это была бы прежде всего существенная переписка движка хранения данных. Стоила бы овчинка выделки?
Это никак не касается "движка хранения". Итак нельзя так жёстко контролить физическое расположение блоков на диске. Блок всётаки может переместиться независимо от желаний скуля (случаи разные бавают).
Да, MS может передать частичный контролить (к примеру недекларируемым функционалом) от ФС к SQL, но в основном физическая фрагментация дело только ФС.
Во вторых, не переписка, данный функционал уже есть как в NTFS, так и в многих других современных жураналируемых ФС.
Более того сама база по себе вообще за этим не следит, это делается спец сервисом и совершенно прозрачно.

Почему-то уверен что это сделали только ради фрагментации. Хотели как лучше, а получилось как всегда.

Кса, уже писал про оптимальность логирования.
2 фев 12, 17:49    [12021569]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
ABC_1982
пропущено...

1. Чтобы удаление снапшота было максимально легким.
2. Чтобы было возможно создание нескольких снапшотов.

Достаточно для начала?
Всё мимо. Никак это не влияет, и скорее даже наоборот.
Сейчас при изменении блок копируется во все снапы. Т.е. при изменении 16K для 10 снапов нужно будет освободить 160K места на дисках (хотя не факт, но по ходу). При их удаленнии надо их все освобождать.
Если было бы сделано кошерно. То нужно было только 16K места для новых данных, уменьшить счётчик у блока на 1 (11 -> 10, 11 это 1 БД + 10 снапов).
А при освобождении только одну копию очистить. Кста, секурити может требовать заполнение мусором (нулями) освободившийся блок.

Так что только две "особенности":
1. Один механизм для снапов - на разных носителей или на одном.
2. Отсутсвие фрагментации основного файла за счёт фрагментации всех её снапов.
3. Не требуется реализации на уровне ФС (но она то там есть + всё равно есть ограничения - NTFS (журналируемая ФС), транзакции то нужны).

Кароче, ж*пнуто сделано, как ни крути.

Так получится какой то жуткий версионный монстр, где при 10 снапшотах, может быть создано до 11 копий одних и тех же страниц данных. С этим будут как минимум такие проблемы:
1. Раздувание основного файла данных
2. Непонятно кто и когда будет вычищать версионный мусор из файла при удалении снапшота.
3. Где хранить все эти линки? И как получать нужную версию данных для снапшота?
4. При обновлении страницы данных таблицы без кластерного индекса помимо перемещение самих данных прийдется обновлять (а как следствие перемещать) страницы все некластерных индексов.

При текущей реализации снапшотов ни одной из этих проблем нет. Есть другие, согласен, высокая нагрузка на диск.
3 фев 12, 05:02    [12023528]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
mwolf
Господа,

хотим использовать Database Snapshots (не путать со snapshot isolation level !) для того, чтобы периодически выгружать данные с помощью bcp . У кого есть реальный опыт работы с этой штукой? Насколько возрастает нагрузка на сервер? Какие могут быть подводные камни?

МСДН почитал. Хотелось бы историй из реальной жизни.

Наша база - порядка 1.5+Т, достаточно много инсёртов, порядка 50к-строк\час апдейтов. bcp по длительности ожидается порядка часа-полтора.

История из реальной жизни.
При включенном снапшоте все изменения перед тем как попадают в основную базу должны быть записаны в файл снапшота. Причем если при обновлении основного файла изменения могут записываться на диск экстентами (по 64кб), то в снапшот только постранично (по 8кб), что как следствие увеличивает количество IO операций записи почти в 8 раз. Если ваши диски к такому не готовы, ждите того что все обновления будет выполнятся медленнее.
3 фев 12, 05:10    [12023530]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mind, опаньки.
Вы хотите сказать, что линки на страницы данных хранятся в файле снапа (как тело файла), а не файловой таблице NTFS?
Посыпаю голову пеплом.
Понятно, MS SQL не имеет доступа к функциям ФС. И возможно я переборщил с NTFS. (Теневое копирование тома для меня встало под вопросом)
И поэтому для снапов хватает только журналированной ФС без системы снапов файлов. Ok.

Т.е. если поменять руками содержимое БД при выключенном сервере (+VSS) или отдельно от снапа, то снап будет невалидный. Ось тут не спасёт.

Только ща до меня дошли изыскания ABC_1982. Как он пытался всунуть логику ФС в работу SQL. :) Похвально.

Mind
3. Где хранить все эти линки?
В файловой системе. Т.е. снапы работают на их уровне, а не на уровне SQL.
Представьте хардлинки, но не на уровне файлов (когда несколько файлов или потоков смотрят на один общий блок данных), а на уровне блочков (когда логические блоки/кусочки файлов смотрят на тотже блок/сектор данных диска).
Мде, вянда не линух. Ещё больше разочарован.

Ок. Логика проста - назависимость от ФС. Тады это нормально.

PS: Такое ощущение что ещё немного и 99% програмного обеспечения будет состоять из обратной совместимость исторических багов. И даже не сколько кода, сколь базовой структуры системы (от ядра гипервизора до JS скриптов).Но при этом ещё на 80% быть копипастой.
Желание быть частью это дикого племени как-то не очень много.
3 фев 12, 11:55    [12024928]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Mind, опаньки.
Вы хотите сказать, что линки на страницы данных хранятся в файле снапа (как тело файла), а не файловой таблице NTFS?
Посыпаю голову пеплом.
Понятно, MS SQL не имеет доступа к функциям ФС. И возможно я переборщил с NTFS. (Теневое копирование тома для меня встало под вопросом)
И поэтому для снапов хватает только журналированной ФС без системы снапов файлов. Ok.

Т.е. если поменять руками содержимое БД при выключенном сервере (+VSS) или отдельно от снапа, то снап будет невалидный. Ось тут не спасёт.

Только ща до меня дошли изыскания ABC_1982. Как он пытался всунуть логику ФС в работу SQL. :) Похвально.

Mind
3. Где хранить все эти линки?
В файловой системе. Т.е. снапы работают на их уровне, а не на уровне SQL.
Представьте хардлинки, но не на уровне файлов (когда несколько файлов или потоков смотрят на один общий блок данных), а на уровне блочков (когда логические блоки/кусочки файлов смотрят на тотже блок/сектор данных диска).
Мде, вянда не линух. Ещё больше разочарован.

Ок. Логика проста - назависимость от ФС. Тады это нормально.

PS: Такое ощущение что ещё немного и 99% програмного обеспечения будет состоять из обратной совместимость исторических багов. И даже не сколько кода, сколь базовой структуры системы (от ядра гипервизора до JS скриптов).Но при этом ещё на 80% быть копипастой.
Желание быть частью это дикого племени как-то не очень много.

Мне кажется что я уже слабо представляю о чем идет речь, что такое линки, как работает файловыа система в линуксе и прочее, но я все же попробую ответить.
В текущей реализиции снапшотов нет никаких линков вообще. Зачем они нужны? Файл снапшота пустой изначально.
Вы же предлагаете какие то линки и счетчики. И если при такой реализации эти хардлинки хранить в файловой системе, то в момент создания снапшота нужно во все блоки снапшота записывать эти линки что-ли? Ну ладно. Допустим в одну сторону у нас связь есть. Снапшот по линкам может "собрать" нужную ему версию данных. А как наоборот? Как блок с данными (не снапшот) узнает какие снапшоты на него ссылаются? Счётчик линков на каждый блок? И обновлять это все при добавлении/удалении снапшотов? Или как?
3 фев 12, 21:21    [12030322]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mind
Мне кажется что я уже слабо представляю о чем идет речь, что такое линки, как работает файловыа система в линуксе и прочее, но я все же попробую ответить.
Эээ ответить на что? Может просто "поддержать разговор", полюбопытствовать, уточнить, указать ошибку.

Mind
В текущей реализиции снапшотов нет никаких линков вообще. Зачем они нужны?
Есть! Вы создаёте снап на БД, и видите, что на допустим 200 Gb базу получили снап размером в 30 метров (в пропертях файла - размер: 200Gb , 30Mb на диске).

Воспользуемся мультиверсумом.

+ Вселенная 1
ROLLBACK LAST POST [Mnior];

Mind
Файл снапшота пустой изначально.
Везвращаемся к ФС. В тех 30 метрах на диске хранится не тело файла, да он "пустой", но есть ссылки (на блоки файла) которые и занимают эти 30 метров. (Возможно реализовано через Alternate data streams)

Mind
в момент создания снапшота нужно во все блоки снапшота записывать эти линки что-ли?
Да. Делается тупо слепок таблицы блоков файла БД - одна команда копирования цельного блока (это очень-очень быстро). + Увеличение на единицу у счётчиков главной таблицы блоков/секторов диска - это чуть сложнее, но тоже быстро. В реале может быть другая стратегия, но логика та же.

Mind
Снапшот по линкам может "собрать" нужную ему версию данных.
Это неважно. Такова структура любого файла современной ФС. Файл на диске занимает палюбэ больше места, чем его размер. Его структурную инфу, как никак надо где-то хранить. Всё сложнее чем в тупой FAT.

Mind
А как наоборот?
Любая запись блока данных любого файла состоит из нескольких шагов. Рассмотрим несколько вариантов когда ФС получает команду "перезапись блока X данными Y". Упрощённо конечно.

Стратегия А:
1. Смотрим количество линков на блок X: N.
2.A. Если оно равно 1му пишем данные поверх. (return)
2.Б. Если оно больше 1го, смотрим по цепочке (список ссылок) на первый файл
3.Б.1.А. Если это наш файл, пропускаем. (continue)
3.Б.1.Б. Иначе делаем копию блока для этого фала (подпроцедура)
4.Б.2. Бегаем по списку, пока не достигнем конца. (while)
5.Б. Пишем данные поверх в блок X.
6.Б. Ставим счётчик в 1цу для блока X
Стратегия Б:
1. Ставим 1цу для нового пустого блока Z.
2. Сохраняем данные в блок Z.
3. Меняем в таблице файла линк с X на Z.
4. Уменьшаем счётчик у блока X на 1цу (N = N-1).
~5. В фоне работает сборщик мусора. Освобождает блоки у которых счётчик равен нулю (0).
Стратегия В:
1. Смотрим количество линков на блок X: N.
2.А. Если оно равно 1му пишем данные поверх. (return)
3.Б. Иначе ставим ставим 1цу для нового блока Z.
4.Б. Сохраняем данные в блок Z.
5.Б. Меняем в файле линк с X на Z.
6.Б. Уменьшаем счётчик у блока X на 1цу (N = N-1).
Количество шагов несоизмерима, в стратегии А больше микрокоманд. Хотя это не важно. Скорость процессоров/чипов не сопоставима со скоростью дисков.

Сейчас в реале работает стратегия А, а мене хотелось бы чтоб работало В или Б или что-то подобное. Может работать и другая стратегия, доработанная А - разница лишь в том что копия делается одна и все снапы смотрят на один скопированный блок (3.Б.1.Б.). Это легко экспериментально проверить.

В NTFS могут быть оптимизации такого рода: для обычных файлов применять упрощённую/другую стратегию:
Не в "файле" хранить линки на блоки главной таблицы, а в главной таблице хранить линки на файлы (аля FAT).
А для файлов снапов или в случае теневого копирования тома использовать вышеуказанную стратегию.

Как альтернатива:
+ Вселенная 2
COMMIT LAST POST [Mnior];
Используя технологию Sparse files в тех 30 метрах хранятся базовые данные о снаповой базе + обычная таблица страниц данных (индексов и куч), но в каждой строке <[см базовую БД]>.

Когдась меняются данные в базовой БД, снапы копируют себе страницу первичных данных (из файла синхронно или из лога асинхронно?) с тем же смещением в файле и восстанавливают строку в таблице страниц.

ABC_1982, как вариант, предложил делать копию только в последний снап, а в таблицах данных снапов писать строку <[см в снап Last]>.
Не думаю что M$ так заморачивалась. Но легко проверить.
--------------------------------------------------------------------
А на самом деле всё может быть ещё проще. В 30 метрах храниться базовая инфа и timestamp полученный из основной БД на момент снапа.
Если timestamp страницы которая должна измениться меньше снапового - копируем её в снап, иначе игнор (она уже там есть).

При чтении данных из снапа:
А. Данный блок есть на диске. Предоставляем.
Б. Ошибка Sparse файла: Missing data. Обрабатываем ошибку чтением из фала БД.
Да, в данном варианте нет никаких явных линков (в базе).

Всё вышесказанное чисто на пальцах без учёта транзакций, кэша, мульти-поточности и всего такого.
4 фев 12, 02:42    [12031455]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Mind
В текущей реализиции снапшотов нет никаких линков вообще. Зачем они нужны?
Есть! Вы создаёте снап на БД, и видите, что на допустим 200 Gb базу получили снап размером в 30 метров (в пропертях файла - размер: 200Gb , 30Mb на диске).
Mind
Файл снапшота пустой изначально.
Везвращаемся к ФС. В тех 30 метрах на диске хранится не тело файла, да он "пустой", но есть ссылки (на блоки файла) которые и занимают эти 30 метров.

То что файл снапшота при создании физически занимает 30 мегабайт вовсе не означает что там какие то линки хранятся. По крайней мере, я не встречал описания подобного механизма работы снапшотов. Но если у вас есть ссылка на такое описание, я бы почитал. 30 мегабайт - это данные измененные активными открытыми транзакциями, которые существовали на момент создания снапшота. Нужно это для того, чтобы привести снапшот в непротиворечивое состоянии. Если транзакций не было, то sparse файл будет минимального размера, а именно 64К. И при этом не важно какого размера была оригинальная база.
20 фев 12, 08:21    [12119950]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mind, вы наверно поняли что я привёл 2 точки зрения (вселенная 1 (алтернативная) и вселенная 2 (реальная)).
Во второй сходится с вашим мнением полнотью (разве не заметили?).
Ссори за то что запутал.

Mind
По крайней мере, я не встречал описания подобного механизма работы снапшотов. Но если у вас есть ссылка на такое описание, я бы почитал.
В том то и оказалось проблема. Я читал об механизме снапов файлов, а вы о снапов MS SQL.
Оказалось что они не сходятся. Ссылку тежело найти, извиняюсь, давно было и неправда.
Лучше здесь привести вашу ссылку на механизм снапов MS SQL.
Могу лишь побыть КО (Rediret-on-write method немного по другому работает).

Mind
Если транзакций не было, то sparse файл будет минимального размера, а именно 64К.
Значит я плохо тестил.

Ok. Sparce файлы (таков выбор MS). Тогда встаёт вопрос. Получается что снапы сильно фрагментированны.
Т.е. чем больше изменений тем больше фрагментация. Т.е. по скорости чтения снапы проседают.
20 фев 12, 12:30    [12121422]     Ответить | Цитировать Сообщить модератору
 Re: Какие могут быть проблемы с database snapshot?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Mnior
Mind, вы наверно поняли что я привёл 2 точки зрения (вселенная 1 (алтернативная) и вселенная 2 (реальная)).
Во второй сходится с вашим мнением полнотью (разве не заметили?).
Ссори за то что запутал.

Да, наверное запутал.

Mnior
Mind
Если транзакций не было, то sparse файл будет минимального размера, а именно 64К.
Значит я плохо тестил.

Ok. Sparce файлы (таков выбор MS). Тогда встаёт вопрос. Получается что снапы сильно фрагментированны.
Т.е. чем больше изменений тем больше фрагментация.

Да, я полагаю что фрагментированы, данные пишутся в порядке изменения в основной БД. Они попытались хоть как-то компенсировать фрагментацию тем что выделяют место в снапшоте экстентами даже если изменилась всего 1 страница. Т.е. в теории read-ahead чтения возможны, но только по 64К + с разных мест на диске.

Mnior
Т.е. по скорости чтения снапы проседают.
А уж как они проседают по скорости записи, точнее тормозят любые изменения в рабочей БД.
22 фев 12, 11:18    [12135446]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить