Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
serg99

в Oracle обозван Serializable

Не только в Оракле он так обозван, но и насколько помню - это вообще стандартизованное название.
18 мар 05, 15:16    [1398113]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
softwarer
В смысле? Можете конкретизировать, что имеете в виду?
Сотни раз уже тема мялась. Он имеетв виду:

-- для всех транзакций устанавливаем isolation level в serializable.
create table a(i int)

-- transaction 1:
delete a where i in (1,2) 
insert into a (i) values (1); 

-- transaction 2:
delete a where i in (1,2) 
insert into a (i) values (2); 
commit; 

-- transaction 1:
commit;

В oracle, после таких упражнений, в таблице "a" окажется две записи, что ни коим образом не удовлетворяет определению serializable.

Нет в oracle честного serializable. Тогда как в Yukon для подобного случая при isolation level snapshot будет выведена ошибка с откатом, что более правильно.
18 мар 05, 15:37    [1398202]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Dooma
Сотни раз уже тема мялась. Он имеетв виду:

Не возражаю. Но иногда в таких ситуациях случается услышать что-то новое..

Dooma
В oracle, после таких упражнений, в таблице "a" окажется две записи,

Отметим - только в том случае, если до того ни одной из таких записей в таблице не было. А тогда пример оказывается.. малоосмысленным, чтобы не сказать "бессмысленным".

Dooma
что ни коим образом не удовлетворяет определению serializable.
Нет в oracle честного serializable.

"Честного" в Oracle действительно не так много. В Oracle в фаворе "практичное".

Dooma
Тогда как в Yukon для подобного случая при isolation level snapshot будет выведена ошибка с откатом, что более правильно.

Можете набросать механику - как именно это будет происходить? Собственно, интересуют два аспекта: есть ли теоретическая возможность подобной ошибки (если действия выполняются одновременно) и какова стоимость такой сериализации.
18 мар 05, 15:56    [1398300]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
softwarer
Отметим - только в том случае, если до того ни одной из таких записей в таблице не было. А тогда пример оказывается.. малоосмысленным, чтобы не сказать "бессмысленным".


Не скажите.

После коммита транзакций должны выполняться условия :-

Транзакция 1:
Запись i=2 не существует
Запись i=1 существует

Транзакция 2:
Запись i=1 не существует
Запись i=2 существует

Это - логика транзакций. И установка serializable не позволяет эту логику реализовать.
18 мар 05, 16:35    [1398487]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Поскольку условия выхода из транзакций противоречивы - одна из них должна быть отменена с соответствующей ошибкой.
18 мар 05, 16:37    [1398498]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
www.fun4me.narod.ru
Не скажите.

Для реализации этого условия существует адекватный механизм (unique function-based index). Если разработчик БД не желает вешать constraint - хм, как обычно, принимает на себя ответственность за последствия.
18 мар 05, 16:46    [1398542]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
www.fun4me.narod.ru
Поскольку условия выхода из транзакций противоречивы - одна из них должна быть отменена с соответствующей ошибкой.

Кстати, не должна. Откатывать транзакцию в момент commit-а - худший из возможных вариантов, но в вашем подходе неизбежный. В моем же случае - будет обычное исключение, которое может быть обработано и в итоге транзакция завершится штатно.
18 мар 05, 16:48    [1398557]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
опять по 5 кругу - mvc, ecalation, сириализибле ... ну никакой фантазии у народа :)

по стандарту - был стандарт 92, в нем описывались только феномины и подогнан был стандарт под блокировочники (их было больше). оракл честно соответствует ansi sql 92. потом в был sql99 вот туда добавили критерий упорядоченности. но к тому моменту все включая МС сказали что сдандарт гавно и в фтопку его.

http://www.osp.ru/dbms/1996/02/45.htm
18 мар 05, 16:55    [1398597]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

Так то оно так. Но, возможно, лучше маловероятная ошибка ORA-01555, чем грязное чтение или блокировака читающим, пишущего,

А при чем здесь грязное чтение и блокировки ? Грязное чтение вообще можно использовать только в особых случаях, блокировки - так я вам говорю о том, что версионность тоже будет включаться только когда нужна, т.е. когда доп. нагрузка из-за версионности компенсирует блокировки.

Alex.Czech

2StallkerS Похоже, вы действительно либо не умеете читать, либо не хотите вчитываться

Да, я не умею читать

Alex.Czech

Еще один момент - я проводил элементарное тестирование
...
и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)

Не ломайте комедию. Тесты на производительность в принципе бессмыслено проводить на бета-версиях. Кроме того, вы что, ожидали что версионные запросы начнут работать быстрее блокировочных ? Использование версионности подразумевает правильную настройку TempDB, если вы еще об этом не в курсе, советую посетить сайт microsoft, прежде чем развешивать указанные вами цифры на всех углах.
18 мар 05, 19:10    [1399056]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

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

При том, что в Оракле они исключены. А када включится версионность в Юниконе, тада посмотрим будет или нет там появляться что-то типа ORA-01555. А нужна она скорее всего всегда. А там где не нужна, там скорее всего одна транзакция на одну таблу. Не знаю что это такое. Возможно однопользовательская БД на домашнем компе?
Кроме того, как она включится? Ведь у блокировочника журнал транзакций, а у версионника журнал повторного выполнения. Тогда у Юникона будут оба вида журналов или он будет все равно с журналом транзакций будет париться в версионном варианте?

2 Dooma

Много мучался с Вашим примером, но он выдает неизменно одну запись i = 2. Две если только Delete во второй транзакции не выполнять.

Но Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.
18 мар 05, 20:00    [1399109]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
>Не ломайте комедию. Тесты на производительность в принципе бессмыслено проводить на бета-версиях.

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

http://www.eweek.com/article2/0,1759,1776031,00.asp
18 мар 05, 20:25    [1399149]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

А када включится версионность в Юниконе, тада посмотрим будет или нет там появляться что-то типа ORA-01555

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

А нужна она скорее всего всегда.

Нет
vadiminfo

А там где не нужна, там скорее всего одна транзакция на одну таблу

Она не нужна в тех задачах, когда число пишуших транзакции гораздо больше читающих.
vadiminfo

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

Насколько понял, это - фактически одно и то-же
18 мар 05, 20:41    [1399184]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
Yo!!

а они только после 3-й бэты будут оптимизацией заниматся.

кто, чем и когда будет заниматься, решать все равно не нам с вами. Мне не хочется разводить флейм по поводу тестов системы, которая еще не зарелизина. Предметно это можно будет рассматривать, только когда выйдут официальные результаты.
18 мар 05, 20:47    [1399189]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

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


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


StalkerS

Нет

Хорошо. Вам не нужна, а мне не помешает.

StalkerS

Она не нужна в тех задачах, когда число пишуших транзакции гораздо больше читающих.

Так случается, что пишушие тоже почитывают.

StalkerS

Насколько понял, это - фактически одно и то-же

А я раньше думал, что это фактически не совсем одно и то-же. Может заблуждался. Надо еще раз почитать про них. Ведь если одно и тоже, то как они обходились до сих пор (пока не перешли из блокировочников в версионники) без сегментов отката? Ведь одних только журналов повторного выполнения не дростаточно для восстановления? Не до конца ясно.
18 мар 05, 22:07    [1399261]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
2vadiminfo. У MS SQL undo и redo информация хранятся в одном файле (transaction log). В каком виде и как - не спрашивайте, я не помню деталей, можно почитать книгу Inside SQL Server, там все достаточно хорошо описано
18 мар 05, 22:18    [1399273]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

Откуда:
Сообщений: 422
vadiminfo
Но Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.


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

В стандарте же качество изоляции определяется отсутствием одного из феноменов
-Dirty Read
-Read Commited
-Repeatable Read
-Phantoms

Однако отсутствие всех этих феноменов (как в режиме Snapshot) автоматически не означает что транзакции являются сериализуемыми. То есть в данном случае Оракл вольно или невольно своим названием serializable вместо snapshot вводит народ в заблуждение.

Скажем в нижнем примере при каждом чтении целочисленного атрибута 1 затем следует его увеличение на единицу и запись.

Trans1              Start Read1 Write1 Commit
Trans2     Start                                          Read1 Write1 Commit
Интересно что при изоляции Read Commited этот сценарий является сериализуемым, то есть сводится к последовательному выполнению транзакций и после выполнения их обоих значение атрибута увеличивается на 2.

В то же время при уровне snapshot (serializable в Оракл) сценарий становится наоборот не сериализуемым. При этом так как Транзакция2 началась раньше, она видит только старое значение атрибута и в итоге после выполнения обоих транзакций атрибут увеличивается на 1 вместо правильных 2 (как было бы при их последовательном выполнении). То есть нарушается логическая правильность состояния БД после выполнения транзакций.

Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?
18 мар 05, 22:25    [1399283]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Alex.Czech
Но я про то и говорю: transaction log - журнал транзакций. Это для блокировочника. Там все про транзакции завершенные и не завершенные - то что ему нужно для восстановления. У версионника Оракла redo.log - журнал повторного выполнения. Там тока инфа про завершенные транзакции, которые он повторно выполнит, если точно не известно что изменения зафиксированы в БД на диске (т.е. изменения после контрольной точки, а undo он возьмет просто из сегментов отката или табл пространств отката просто блоки до изменений). Значит разница есть между журналами транзакций и журналами повторного выполнения?
18 мар 05, 22:56    [1399314]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
Разница в том, что у Оракла это два разных журнала, и запись туда ведется независимо, а у MSSQL один, и там инфа хранится вместе, по-моему она даже переплетена... сейчас я поищу книжку, она у меня лежит где-то в электронном виде
18 мар 05, 23:07    [1399320]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
The transaction log records all changes made to the database and stores enough information to allow any changes to be undone (rolled back) or redone (rolled forward) in the event of a system failure or if it is told to do so by the application (in the case of a rollback command). Physically, the transaction log is a set of files associated with a database at the time the database is created or altered. Modules that perform database updates write log entries that exactly describe the changes made. Each log entry is labeled with a log sequence number (LSN) that is guaranteed to be unique. All log entries that are part of the same transaction are linked together so that all parts of a transaction can be easily located for both undo activities (as with a rollback) and redo activities (during system recovery).
18 мар 05, 23:10    [1399322]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 serg99

>Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?

На практике однозначно задумываются и прменяют либо оптимистические блокировки либо писсемистические.

Мне кажется, что в Вашем примере возникает, та ситуация про которую говорил www.fun4me.narod.ru. И я считаю, что тразакция 2 (правда я read1 мысленно подвинул к start) должна быть отменена. Т.е. юзер должен получить любимое - "запись изменена другим пользователем" (оптимистическая блокировка) или он должен был заблокировать транзакцию после чтения. Иначе мы доиграимся. Все-таки второй юзер хотел увеличить только на 1, то что прочитал, а оно вдруг изменилось на 2?! Опять уточняю, что read1 мысленно подвинул к start у второй транзакции для типичности. Или Вы намерено сделали между ними разрыв, чтобы непонятней было какую из них нужно все-таки отменить?
18 мар 05, 23:41    [1399338]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Alex.Czech
Ну про журнал транзакций для блокировочников Вы пишите то, что я про них и думал. Я читал про них в общей литре по БД, где описывается упрощенная архитектура СУБД на примере блокировочника.
Что до оракла ту него только журнал повторного выполнения, хотя и реализован в виде нескольких файлов. Как минимум двух, но типично из трех. Ну, еще могут быть включены архивные журналы повторного выполнения. Ими защищены и undo сегменты. Но это не журналы, а копии блоков данных до начала изменения. Отсюда собственно и термин многоверсионность - несколько версий данных. Эти андо используются не только для чтенеия на уровне READ COMMITED, но и для отмены незавершенных транзакций при восстановлении после сбоев. Об этом кстати есть тоже в общей литре по БД.
18 мар 05, 23:59    [1399349]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

Откуда:
Сообщений: 422
vadiminfo
Мне кажется, что в Вашем примере возникает, та ситуация про которую говорил www.fun4me.narod.ru. И я считаю, что тразакция 2 (правда я read1 мысленно подвинул к start) должна быть отменена. Т.е. юзер должен получить любимое - "запись изменена другим пользователем" (оптимистическая блокировка) или он должен был заблокировать транзакцию после чтения. Иначе мы доиграимся. Все-таки второй юзер хотел увеличить только на 1, то что прочитал, а оно вдруг изменилось на 2?! Опять уточняю, что read1 мысленно подвинул к start у второй транзакции для типичности. Или Вы намерено сделали между ними разрыв, чтобы непонятней было какую из них нужно все-таки отменить?


Я специально сделал разрыв. То есть инкремент атрибута может происходить в разных транзакциях и/или разных приложениях и/или разных клиентах, а планировщик ОС сервера может по разному планировать нити исполнения разных транзакций. То есть вполне возможно как в приведенном примере, что транзакция_1 ПОЛНОСТЬЮ завершится ДО того как с атрибутом начнет работать транзакция_2 начатая раньше. А так как в версионниках при snapshot транзакция начинается как правило с создания локальной копии TIP, то транзакция_2 вообще не видит транзакцию_1 даже когда та закоммитится. В данном случае так же не нарушается правило, что одновременно может существовать только одна незакоммиченная версия записи, при этом транзакция_1 "при жизни" не знает наперед что будет делать транзакция_2.

То есть получается, что для борьбы с этим феноменом нужно вручную в начале транзакции блокировать ресурс который транзакция собирается или может изменить, чего можно было бы избежать если бы СУБД поддерживала настоящую сериализуемость транзакций.
19 мар 05, 00:59    [1399368]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
2vadiminfo. Я в курсе как оно у Оракла, спасибо :) Насчет того как будет работать Yukon с транзакшн логом - так же как и раньше видимо. Поживем-увидим
19 мар 05, 01:54    [1399398]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

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

Это уже является проблемой правильного проектирования базы, а никак не проблем в работе сервера. Кроме того, использование отдельного места для хранения версий как раз более устойчиво к такого рода ошибкам, так как TempDB будет самостоятельно расти, а rollback сегменты придется сразу задавать очень большого размера, расходуя понапрасну память.
vadiminfo

Хорошо. Вам не нужна, а мне не помешает.

Странный ответ. Вы базы что, для личного пользования делаете ?
vadiminfo

Так случается, что пишушие тоже почитывают

Так я говорю о процентном отношении пишуших и читающих
vadiminfo

Эти андо используются не только для чтенеия на уровне READ COMMITED, но и для отмены незавершенных транзакций при восстановлении после сбоев

В SQL-Server лог транзакций используется для отката транзакций в случае выполнения команды rollback или возникновения ошибки, восстановления всех незавершенных транзакций в случае аварийного перезапуска сервера, восстановления базы в случае отказа винтов вплоть до момента отказа. Но необходимые данные содержаться в самом журнале.
Принципиальная разница Оракла в том, что у него журналы повторного выполнения используются только для восстановления после сбоя, а простой откат транзакции выполняется по информации из сегментов отката. Т.е. при изменении данных, в Оракле генерируется новые блоки сегментов отката и данные журнала повторного выполнения, а в SQL-Server - все данные о транзакции отправляются в журнал
19 мар 05, 07:42    [1399449]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 serg99
Я воспроизвел Ваш пример. При попытке добавленя 1 в транзакции 2 получили сообщение об ошибке ORA-08177 can't serialize access for this transaction
А в литре по БД пояснение, что в этом случае в приложеннии должно быть предусмотрено повторное выполнение этой транзакции. Т.е. получается последовательный график транзакций. Т.е. не всегда надо в ручную вначале транзакции блокировать никакой ресурс. Достаточно установить ISOLATION_LEVEL = SERIALIZABLE. Я использовал update. А тут видно, что нюансы начинаются с инсертами. Поскольку до инсетра в пустой БД еще ничего не было, наверное. Буду смотреть этот вопрос дальше.

2 Dooma
Я извиняюсь, вчера не заметил, что девелопер настроен коммитить любую операцию, поэтому и не получалось.



StalkerS

Это уже является проблемой правильного проектирования базы, а никак не проблем в работе сервера.

Вы идtализируете проектирование базы. Ну хорошо ORA-01555 - результат того, что система не до конца правильно спроетирована. Не учли ситуации, не все просчитали, наделали ошибок в ХП. Ну их наделают и в Юконе. Или нет?

StalkerS


так как TempDB будет самостоятельно расти, а rollback сегменты придется сразу задавать очень большого размера, расходуя понапрасну память.

Но я говорил Вам о том, что, начиная с Оракле 9 можно явно задать время, которое нельязя перезаписывать блоки отката. Ну и тоже будет расти. Там есть понятие табличных пространств отката, а не только сегментов отката. Вы можете использовать и то и другое. При использовании табличных пространст можете написать время.


StalkerS

Странный ответ. Вы базы что, для личного пользования делаете ?


Исключительно не для личного, потому так и говорю - если есть версионность ее предпочту однозначно? и не буду замарачиваться. Потому что нужны слишком серьезные доводы, чтобы ее не применять, а пока я знаю только один - СУБД в принципе не поддерживает версионности. Ну, может быть система для одного пользователя, тогда тоже не имеет особого значения.

StalkerS

Так я говорю о процентном отношении пишуших и читающих

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



StalkerS

Принципиальная разница Оракла в том

Так я Вам и говорил именно про эту разницу. Т.е. про разницу между журналами тразакций и повторного выполнения. А Вы, вроде, говорили, что нет разницы. Добавлю, что использует эти данные сегментов отката не только для воостановления, но для обеспечения уровня изоляции READ COMMITED. Т.е. собственно для своей многоверсионности. Т.е. для двух целей использует сегменты отката. Потому и спарашивал Вас, что SQL-Server будет по прежнему пользоваться журналами транзакций в многоверсионном режиме? Не будет использовать эти блоки старой версии? Вроде, на первый взгляд, как-то не оптимально получается тогда.
19 мар 05, 14:41    [1399675]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить