Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
Merle
Guest
Произошёл сбой БД. Допустим, удалили таблицу. Как её восстановить в MS SQL ?
Ну с этой стороны не подкопаетесь. ;)
Все реализовано ни чуть не хуже, а местами даже и лучше чем в других БД.
При наличии вменяемого админа восстановление до любого момента времени производится в три команды. Это не бином ньютона.

И вообще, тогда заодно хотелось бы получить описание процесса восстановления в MS SQL Server. Какие там есть процессы, кто за что отвечает, как сервер определяет изменения данных, и какие из этих изменений нужно накатить, а какие уже есть. А заодно и внутреннее устройство самого SQL Server
Да Вам палец в рот не клади, может еще и государственный секрет какой-нибудь выдать?.. ;)
Logging и Recovery в MSSQL работают на основе протокола опубликованного Моханом в 91 году. Алгоритм на редкость удачный и не самый сложный в реализации, по мимо MS в СУБД его используют IBM (DB2) и Sybase (ASA).
(А не в субд и не сосчитать)
Так что за всеми подробностями работы журналирования в MS отсылаю к описанию этого алгоритма, детали реализации, естественно, являются коммерческой тайной.

В оракле случае повреждения какого-либо журнального файла у меня потеря данных минимизируется благодаря нескольким журнальным группам, а не одному файлу.
Нет ни каких проблем и в MS, в случае необходимости, разнести журнал на несколько файлов.

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

Где они хранятся внутри самого сервера?
Данные? В Buffer Manager'е, а что Вы хотели этим прояснить?

Что касается первоначального сообщения - не знаю какую там функциональность урезает MS, но в доступной мне версии юкона Hash Partitioning летает как трофейный мессершмит. Может они конечно и исключат это из финальной версии, но что-то я сомневаюсь..
13 май 04, 16:26    [676713]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Merle
Это азы БД. Любая субд, претендующая хотя бы на зачатки Recovery обязана сбрасывать данные на диск при фиксации транзакции, и MS здесь не исключение. Пока данные не доедут до журнала, транзакция не считается закоммиченой


А вот Том Кайт считает не так Он пишет, что в Oracle журналы пишутся В ПРОЦЕССЕ выполнения транзакции, а при фиксации записывается лишь специяльная логическая пометка, о том, что транзакция завершена. Таким образом, какой-бы длинной не была транзакция, commit выполняется одинаково быстро.
13 май 04, 16:54    [676855]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
А вот Том Кайт считает не так Он пишет, что в Oracle журналы пишутся В ПРОЦЕССЕ выполнения транзакции, а при фиксации записывается лишь специяльная логическая пометка, о том, что транзакция завершена. Таким образом, какой-бы длинной не была транзакция, commit выполняется одинаково быстро.
Во-первых, в этом месте я полностью согласен с томом кайтом (в отличии от других мест), я лишь хотел сказать, что в момент, когда сервер говорит, что транзакция зафиксирована - все данные обязаны быть на диске. А уж как они это делают в процессе транзакции - дело сервера. MS вообщем тоже не ждет Commit'а чтобы данные сбросить - у него полноценный redo/undo logging.
А во вторых и в Оракле, строго говоря, при commit'е не только метка ставится.
13 май 04, 17:04    [676905]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
> Таким образом, какой-бы длинной не была транзакция, commit выполняется
> одинаково быстро.
>
Угу...
Или я неправильно понимаю, или... Оракл - версионник? Каждому отдается своя версия? Если да, то при commit надо проверить, что никто не поменял того, что поменял ты. Правильно? Если это так, тогда утверждение насчет "одинаково быстро" какое-то странное... Может, "Одинаково медленно" или "зависит от объема данных, измененных транзакцией"?
В MS SQL точно сразу пишется на диск и commit происходит тут-же, а вот rollback... от 1 до 3 раз дольше самой транзакции (субъективно)
13 май 04, 17:09    [676929]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895
автор
Если да, то при commit надо проверить, что никто не поменял того, что поменял ты. Правильно?

Нет НЕправильно!
13 май 04, 17:11    [676935]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Или я неправильно понимаю, или... Оракл - версионник? Каждому отдается своя версия? Если да, то при commit надо проверить, что никто не поменял того, что поменял ты. Правильно?
Нет, Оракл, конечно, отчасти версионник, но разборки из-за конфликта версий производятся не при коммите, а в момент изменения. Менять позволено только зафиксированную версию данных - опоздавшая транзакция (или запрос, в зависимости от уровня изоляции) откатывается.
Сброс данных происходит либо в момент заполнения буфера, либо по прошествии какого-то времени (сейчас уже не помню какого), либо при коммите, если в момент фиксации в буфере еще есть какие-то данные.
Ни каких дополнительных проверок при коммите не производится, не актуальные данные просто не получится изменить и до коммита дело не дойдет.
13 май 04, 17:33    [677044]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
2Merle
Logging и Recovery в MSSQL работают на основе протокола опубликованного Моханом в 91 году.

не могли бы ссылочку подкинуть - хочеться реализовать в домашней разработке
13 май 04, 23:55    [677488]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, мне очень нравится, то что в Oracle журнал не используется для rollback. Он используется ТОЛЬКО для последовательной записи и это РУЛЕЗ.
Значит в журналах MS SQL данные о транзакциях разных сессий также равномерно размазаны по журналу ?
14 май 04, 08:17    [677635]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
2 Lepsik
Вот тут есть некоторое описание:
Семейство алгоритмов ARIES
Сергей Кузнецов, Петр Чардин
14 май 04, 09:49    [677780]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Borland
Member

Откуда: $HOME
Сообщений: 15839
2 Glory : Согласен, немного туманно сказал. БД master является аналогом репозитория в оракле, однако без репозитория оракловые базы могут преспокойно работать, а без master сиквельные базы - нет.

Уточню вопрос - то, что в случае обвала словаря данных в сиквеле и обвала лога данные можно восстановить на момеент последнего бэкапа это понятно. Интересует вот что : допустим у меня 4 лога. При заполнении первого лога как себя дальше сиквел ведёт? Начинает вести запись во второй? Или продолжает в первый? После заполнения всех четырёх логов что происходит? Они очищаются, или расшираются? Архивируются ли они автоматом, или нет? Производится очистка лога, если логи не архивируются или нет? И как кстати происходит откат транзакции, раз уж всплыла эта тема?

2 Merle :
>>Да Вам палец в рот не клади, может еще и государственный секрет какой-нибудь выдать?.. ;)

Госсекрет выдавать будете иностранным шпионам, если совесть позволит, а меня они абсолютно не интересуют. Оракл не делает из этого тайны за семью печатями, хоть и не является опенсорсом. Там всё достаточно прозрачно и можно достаточно лего определить, где именно происходит затык при работе, как происходит процесс восстановления, какой фоновый процесс какие действия выполняет. Интересует тоже самое в сиквеле: какие есть фоноыве процессы, какие структуры памяти, какой процесс за что отвечает?


-----
Все великие дела совершаются в командной строке
14 май 04, 09:55    [677796]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Borland
Согласен, немного туманно сказал. БД master является аналогом репозитория в оракле, однако без репозитория оракловые базы могут преспокойно работать, а без master сиквельные базы - нет.
Master скорее надо сравнивать с CONTROL-файлами oracle, без которых oracle то же не запустится. MS хранит словарь БД локально в самой БД (БД здесь надо рассматривать с точки зрения MS). Если провести аналогию в oracle, это если бы oracle словарь схемы хранил бы в самой схеме (может и не очень удачное сравнение, но по смыслу близко).

Borland
Интересует вот что : допустим у меня 4 лога. При заполнении первого лога как себя дальше сиквел ведёт? Начинает вести запись во второй? Или продолжает в первый? После заполнения всех четырёх логов что происходит? Они очищаются, или расшираются? Архивируются ли они автоматом, или нет? Производится очистка лога, если логи не архивируются или нет?
Как ведет себя сиквел, сильно зависит от того какая модель восстановления была выбрана. Если простая модель, то сиквел вычистит не нужные записи о транзакциях и будет писать в тот же файл (может и до второго лог-файла не дойдет), Если модель full или bulk-logged, то будет заполнять фаил за файлом или расширять до следующего backup-а. В oracle просессы ARCn занимаются архивированием логов, в сиквеле backup снимается прямо с рабочего лога, без остановки базы, а вот каким там процессом - хер его знает.

Borland
Оракл не делает из этого тайны за семью печатями, хоть и не является опенсорсом. Там всё достаточно прозрачно и можно достаточно лего определить, где именно происходит затык при работе, как происходит процесс восстановления, какой фоновый процесс какие действия выполняет.
В том, что не делает тайны - может и молодцы. Где затык в работе, найдете и в MS.
14 май 04, 11:06    [678026]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
не могли бы ссылочку подкинуть - хочеться реализовать в домашней разработке
Ну Яи Ёжик уже дал, оригинальный доклад зесь, но за бабки:
http://portal.acm.org/citation.cfm?id=128770&coll=portal&dl=ACM&CFID=21522737&CFTOKEN=94092764
В открытом доступе не встречал...

Кстати, мне очень нравится, то что в Oracle журнал не используется для rollback. Он используется ТОЛЬКО для последовательной записи и это РУЛЕЗ.
Это не рулез, а от бедности. Ввиду того, что в Оракле откат является совершенно штатной ситуацией, и число откатов гораздо больше чем в классическом блокировочнике, то сведение undo и redo лога в одном месте при серьезной нагрузке было бы фатальным. Так что это вынужденная мера, блокировочнику подобное разделение никакой серьезной пользы не принесет.

После заполнения всех четырёх логов что происходит? Они очищаются, или расшираются? Производится очистка лога, если логи не архивируются или нет?
Все под контролем, как настроишь, так и будет.

И как кстати происходит откат транзакции, раз уж всплыла эта тема?
В ссылке от Я и Ёжик все достаточно подробно расписано, без конкретных деталей, конечно, но их и Оракл Вам не раскроет.

Там всё достаточно прозрачно и можно достаточно лего определить, где именно происходит затык при работе, как происходит процесс восстановления, какой фоновый процесс какие действия выполняет.
Да и в Сиквеле это никаких проблем не составляет, благо и документация не самая плохая, и подробной литературы хватает, в том числе и теоретической по используемым алгоритмам, и, в крайнем случае, доступны сами разработчики.

какие есть фоноыве процессы, какие структуры памяти, какой процесс за что отвечает?
Ввиду того, что у MSSQL не задачи работать на всем, включая кофеварку, то в основном за все отвечает один процесс, на win так оптимальнее.
Все достаточно подробно расписано в BOL и у Делани. Или Вы ждете, что Вам здесь мегабайтные источники цитировать будут?
14 май 04, 11:31    [678129]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
При заполнении первого лога как себя дальше сиквел ведёт? Начинает вести запись во второй? Или продолжает в первый?
Если первый заполнен то в него писать уже ничего нельзя. Поэтому пишется во второй. И тд

После заполнения всех четырёх логов что происходит?
генерируется ошибка

Они очищаются, или расшираются?
Могут очищаются - см. выше мое сообщение про "время жизни транзакции в логе"
Может автоматически расширяться если это задано его свойствах

Архивируются ли они автоматом, или нет?
Автоматом ничего не архивируется

Производится очистка лога, если логи не архивируются или нет?
зависти от выбранной recovery model

И как кстати происходит откат транзакции, раз уж всплыла эта тема?
Kalen Delaney, Inside SQL 2000 или BOL. Ибо начинать придется с физической организации файла данных и файла журнала. В кратце - происходит восстановление страниц данных на основе информации в файле журнала.
14 май 04, 11:50    [678220]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 Merle

Правда ? Юкону тоже не принесет ?
Rollback не является штатной ситуацией, его следует всячески избегать. Просто Вам не по нраву красивое решение от Oracle IMHO
14 май 04, 12:06    [678302]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Merle
Ввиду того, что в Оракле откат является совершенно штатной ситуацией


Надо понимать, что имелось в виду то, что если для транзакций T2, T3, ..., TN могут понадобиться данные, изменнённые незакоммиченной транзакцией T1, для них производится поиск прошлых версий данных в сегментах отката. Иначе звучит глупо. Количество откатов транзакций определяется, по большей части, спецификой работы приложения.
14 май 04, 12:14    [678337]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Правда ? Юкону тоже не принесет ?
Зря смеетесь.
И Юкону не принесет, там за данными для реконструкции версий в лог не надо будет лезть.

Rollback не является штатной ситуацией, его следует всячески избегать
Как его не избегай, а в Оракле, как впрочем и в версионниках он штатная ситуация, причем в оракле даже больше чем в обычных версионниках.
Любая RW транзакция и даже просто Write-запрос может нарваться на откат, причем чем сильнее нагружена система тем больше вероятность этого отката и избежать этого никак нельзя.

Просто Вам не по нраву красивое решение от Oracle IMHO
Да нет, почему же, для Оракл это выход, но применять его в MSSQL'е, как и в другом блокировочнике, смысла не имеет.
Так что глупо говорить об этом как о преимуществе, это просто одно из относительно удачных технических решений конкретной задачи, которое, однако, мало пригодно в других ситуациях.
14 май 04, 12:20    [678364]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Надо понимать, что имелось в виду то, что если для транзакций T2, T3, ..., TN могут понадобиться данные, изменнённые незакоммиченной транзакцией T1, для них производится поиск прошлых версий данных в сегментах отката
И это тоже, я бы даже сказал - это основная причина.

Но тем не менее..
Количество откатов транзакций определяется, по большей части, спецификой работы приложения.
А что, конфликт версий в RW транзакциях научились решать без откатов?
14 май 04, 12:22    [678381]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 Merle

В Oracle все-таки меньше чем в IB
А если без смеха, меня настораживает попытка сделать версионник посредством tempdb :( Мне нравится MS SQL 2000 и я боюсь, что Юкон станет такой-же малопонятной штукой как Тенджи в Oracle :(((
14 май 04, 12:26    [678397]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Что имеется в виду под "конфликтом версий при RW-транзакциях"?
14 май 04, 12:35    [678440]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
В Oracle все-таки меньше чем в IB
Больше :) Ну как минимум не меньше.
Просто я довольно смутно представляю себе механизм работы транзакций в IB, но факт, что Оракл делает больше откатов, чем необходимо для корректной работы версионника.

А если без смеха, меня настораживает попытка сделать версионник посредством tempdb
Напрасно, то что я видел - мне понравилось.. ;)
14 май 04, 12:37    [678451]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Что имеется в виду под "конфликтом версий при RW-транзакциях"?
r1[x] w1[x] w2[y] w2[x] c1 ...
Что будет делать вторая транзакция? При разных уровнях изоляции ?
14 май 04, 12:48    [678505]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Вы можете как-то аргументировать это не меньше ?
14 май 04, 12:51    [678515]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Merle
Guest
Вы можете как-то аргументировать это не меньше ?
Он откатывает отдельные запросы при RC уровне изоляции, в чем с формальной точки зрения нет никакой необходимости.
14 май 04, 14:15    [679028]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пример можно ? А то я с детства туповат :(
14 май 04, 14:24    [679066]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
use-se
Member

Откуда: Москва
Сообщений: 449
Вопрос можно. Я не за белых и не за красных, но интересно. Кто то из разработчиков, кто работал с Oracle (у меня вер. 9.2) добровольно перешел на другую СУБД? Если да то основная причина.
Спасибо.
14 май 04, 14:50    [679200]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить