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

Откуда: С-Петербург
Сообщений: 2347
)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))
13 май 05, 14:06    [1536806]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
gardenman
)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))


Вовсе не обязательно
13 май 05, 14:08    [1536824]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Vadim_Maximov
Member

Откуда: Москва
Сообщений: 3571
AlexCzech
gardenman
)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))


Вовсе не обязательно

Поясните плз, как по-вашему может возникнуть подобная ситуация в Oracle?
13 май 05, 15:08    [1537187]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
Долгостроящиеся отчеты это классический пример. Версионник предоставляет их на момент начала запроса восстанавливая при необходимости старые версии данных. Блокировочник на момент окончания запроса. Версионник может вылетить с ошибкой snapshot too old если у админа руки кривые, а блокировочник может кучу операций заблокировать либо зам запнуться и ждать окончания транзакции неизвестно сколько. Для блокировочника с этой целью вводятся обычно вспомогательные таблицы что есть таже самая цена которую платит версионник местом для undo информации.

И вообще что есть актуальность отчета при постоянно идущими операциями к базе. Когда начальник берет в руки распечатку отчета он уже не актуален, так что минутами раньше или позже это уже не принципиально. Если уж нужно оперативное его получение, то стоит задуматься о материализованных представлениях, где конечные данные отчета хранятся поддерживаются в готовом или полуготовом виде.
13 май 05, 15:23    [1537263]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.
13 май 05, 15:44    [1537387]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
gardenman
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.


Ну не у всех комунизм, и идеальная система,
у некоторых, сотни пользователей меняют данные, в т.ч. за прошедший перод, и при этом за это же время нужно делать отчеты, и это считается вполне нормальным.
13 май 05, 15:58    [1537487]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
DimaR
gardenman
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.


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


Это вы налоговой инспекции объясняйте, а не мне
13 май 05, 16:05    [1537519]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
michael_
Member

Откуда: Москва
Сообщений: 600
AlexCzech
gardenman

Мысль такова - что долгоиграющие отчеты по нестабильным данным - обсолютно не имеют смысла.


Вы это лучше не мне рассказывайте, а гендиректору клиента, который запросил оборотно-сальдовую ведомость, и у него по дебету получилось 2 миллиона, а по кредиту 2 миллиона 15 копеек


Если проводки в базе лежат двусторонние, то есть в одной строке таблицы Дт, Кт, Сумма, то у Вас дебет всегда с кредитом сойдется, хоть это версионник, хоть блокировочник, хоть файл-сервер
13 май 05, 16:22    [1537610]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
DimaR
gardenman
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным. Обычно тот же баланс/оборотка/сальдовка получается за прошлый день(месяц, год) И тут хоть блокировочник, хоть версионник, хоть снапшот, хоть грязное чтение - результат должен быть всегда один и тот же.


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


Ну тогда без разницы, снапшот или грязное чтение.
Последнее - экономичнее :)
13 май 05, 16:22    [1537614]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
Vadim_Maximov
AlexCzech
gardenman
)) в этом случае ошибку наверняка следует искать не принципах работы СУБД, а .. например в округлениях при конвертации..) или в кривых руках разработчиков))


Вовсе не обязательно

Поясните плз, как по-вашему может возникнуть подобная ситуация в Oracle?


Это либо не ко мне вопрос, либо если ко мне - то у нас это было вовсе не в Оракле, а как раз таки в MS SQL
13 май 05, 16:24    [1537622]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Желтoпузый дьявoл
Member

Откуда:
Сообщений: 113
gardenman
В том то и суть, что долгоиграющие отчеты строятся по уже закоммиченным данным.


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

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


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

Еще раз. При постоянно работающей базе уже не принципиально на какой момент отчет актуален - на момент начал запроса или на момент выхода бумаги из принтера. Не принципиально потому что база все равно изменяется, и на момент прочтения отчета данные уже другие. Это как электрический счетчик. Глянул его, внес данные и пошел платить а он крутит себе дальше.
13 май 05, 16:30    [1537653]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

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

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

в общем, вы изобрели свой собственный вариант реализации версионности, и пытаетесь доказать, что он лучше, чем у microsoft. Занятие это конечно увлекательное, но совершенно бесполезное.

Я к примеру, с трудом представляю себе реализацию, когда версии будет наполовину читаться из лога, а наполовину - из таблиц в обход блокировок. Это фактически - грязное чтение. Наверно, весело программировать реализацию, которая будет гарантировать целостность при таком подходе (прежде, чем считать значение поля, надо убедиться, что в логе нет данных о том, что оно уже успело поменяться, а в логе их кстати, может еще и не быть, там буфер лога есть и пр. приколы). А самое главное зачем ? Что-бы сэкономить на копировании записи ? А вам не приходит в голову, чем выльется эта экономия при чтении версии ? Какую массу работы надо будет произвести, что-бы получить версию в нормальном виде ?
SergSuper

Зато не надо в два места писать. Можно было бы лог как-то оптимизировать

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

Т.е. вы только подтвердили что я написал: версии делают только snapshot-транзакции

Ну а тут я и вообще не понимаю, о чем речь. Согласно правилам русского языка, выражение "версии делают только snapshot-транзакции" означает, что snapshot сами делают версии, что противоречит обьективной реальности. Что вы тут имеете в виду - тайна за семью печатями.
13 май 05, 19:15    [1538346]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Лог оптимизирован для записи, и если из него начнется чтение - то будет проседать производительность пишущих транзакций. Так как во время чтения из лога нельзя туда ничего писать. Что и наблюдается при транзакционной репликации и при дифференциалных бекапах. К тому же информация в лог попадает в основном, исключая коммиты, асинхронно - так как есть WAL. Поэтому из лога нельзя однозначно восставновить текущее состояние записи - есть вероятность что информация об этом в лог еще не попала, а лежит в буферах в памяти. Но если все же начать читать из лога, и использовать буфера для сбора недостающей на диске информации - то работать это будет намного медленнее решения которое оптимизировано на чтение.
13 май 05, 22:02    [1538554]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
Уважаемый andsm
Не уверен, что log оптимизирован только для записи.... Ибо если он оптимизирован только для записи тогда время восстановления должно быть в гораздо больше времени резервного копирования, что не так. Не понятно почему его нельзя будет читать и писать одновременно, как тогда по вашему MS-SQL и DB2 откатывают транзации???? Также при репликации (которая сделана через чтение лога) в DB2 сильного просаживания что-то не видно... Я в данный момент разбираюсь как это все устроено в Oracle, что-то не видно что там тоже все ориентированно под запись. Хотя я до конца еще не разобрался.
14 май 05, 18:09    [1541121]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Транзакции откатываются в разы медленнее чем они коммитятся. При этом как правило для отката транзакции не нужно ничего читать из лога, вся эта информация есть в буферах в памяти. Вообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении. При этом естественно нужно чтобы после коммита не было чекпойнтов. Ну и вспоминая прочитанные книги - в них тоже говорилось что лог оптимизирован для записи.
Почему нельзя одновременно читать и писать. Пусть у нас есть диск, предназначенный только для лога. Ну или рекомендуемый RAID1 для лога. Заметной разницы между обоими случаями нет. Пришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе. В это время исполняются транзакции. Пришел commit, от одной из транзакций. Commit - это синхронная операция, ей нужно дождаться окончания записи всей информации о транзакции на диск. На момент пока идет поиск нужного сектора, чтение из него, в лог ничего не пишется - головки не на том месте. Т.е. ждут коммиты - и видно увеличение времени некоторых транзакций, которые идут в это время. В счетчиках виден всплеск времени ожидания на запись в лог. Это вполне реальная наблюдаемая проблема - в момент работы репликации, когда агент читает лог, идет рост времени прохождения транзакций с 20-30 ms до 100-400 ms. Из-за этой проблемы меняем дисковую систему на более скоростную (и во много раз дороже) - при том что у нас и так была скоростная система - лог на аппаратном RAID1, скази, 15000 RPM. Думаю в DB2 такая же проблема с репликацией - в MS SQL транзакционная репликация тоже сделана через чтение лога.
14 май 05, 19:40    [1541238]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
nkulikov
Guest
автор

Транзакции откатываются в разы медленнее чем они коммитятся.

Потому как для коммита нужно сбросить буффер журнала, и почистить блокировки, а для отката вернуть все сделанные изменения взад :)
В общем случае время отката примерно равно времени превыдущих изменений.

автор

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


Неужели... Мне кажется в общем случае это не так, как минимум это зависит от размера транзакции.

автор

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

Я примерно про это, только в DB2 checkpoints нету. Так что сравнивать нужно для каждой БД по отдельности. Мой опыт говорит, что время отката процентов на 5 больше времени всех превыдущих изменений. И беда отката не в том что он на 5 процентов больше, а в том что все остальные ждут пока он произойдет.

автор

Почему нельзя одновременно читать и писать. Пусть у нас есть диск, предназначенный только для лога. Ну или рекомендуемый RAID1 для лога. Заметной разницы между обоими случаями нет. Пришел запрос, например от агента транзакционной репликации - прочитать такой-то кусок лога. Головки диска пошли искать это место в логе.
В это время исполняются транзакции. Пришел commit, от одной из транзакций. Commit - это синхронная операция, ей нужно дождаться окончания записи всей информации о транзакции на диск.


В общем случае это не вся информация, а только часть (буфер)
Да увеличение будет, но это не связано с тем что лог оптимизирован только под запись. Возможно в вашей задаче это так, но у меня в задачах в разы увеличения не было. Опять же задачи, то разные....
16 май 05, 14:46    [1544129]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Внимательный читатель
Guest
andsm
...При этом как правило для отката транзакции не нужно ничего читать из лога...

А когда нужно, можно подробнее?

andsm
Вообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении.

Так все-таки, для чего же он оптимизирован - для записи или чтения. Или того и другого?


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

А можно ссылочку (в доке или еще где), где об этом можно прочитать?
16 май 05, 18:33    [1545304]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Внимательный читатель
andsm
...При этом как правило для отката транзакции не нужно ничего читать из лога...

А когда нужно, можно подробнее?

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

Внимательный читатель

andsm
Вообще-то на основе этого еще нельзя сказать что лог оптимизирован только для записи - скорее надо сравнить время на запись в лог какой-то длинной транзакции, и время на ее redo при восстановлении.

Так все-таки, для чего же он оптимизирован - для записи или чтения. Или того и другого?

Я думаю что для записи. Мнение основано и на своем опыте, и на прочитанной литературе.
Внимательный читатель

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

А можно ссылочку (в доке или еще где), где об этом можно прочитать?

Про то как идет чтение с диска или как работает LogReader agent? Про чтение с диска описано во многих книгах, про LogReader можно прочиать в BOL
17 май 05, 16:07    [1548399]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
bantik
Member

Откуда:
Сообщений: 516
Господа посмотрите на топик, а заодно на адрес пишущего ...
Многие вопросы уже получили ответ, но у меня еще больше новых появилось :-)

23 май 05, 11:09    [1563375]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
bantik
Member

Откуда:
Сообщений: 516
bantik
Господа посмотрите на топик, а заодно на адрес пишущего ...
Многие вопросы уже получили ответ, но у меня еще больше новых появилось :-)

http://forum.privet.com/viewtopic.php?t=48469&postdays=0&postorder=asc&&start=25&sid=09cc356d703e1d9731da2d319bdb25f3
23 май 05, 11:11    [1563384]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
vadiminfo
Member

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

в общем, вы изобрели свой собственный вариант реализации версионности, и пытаетесь доказать, что он лучше, чем у microsoft.

Так это изобретение как раз у microsoft.

Поэтому далее Ваши рассуждения про грязное чтение относятся к нему же.

Меня удивляет тока то, что Вы верите, что так легко можно опровергнуть общепризннанные факты. Я про то, что Вы скорее всего попытаетесь сказать, что в Оракле грязное чтение. Этого вроде не утвержает и самый microsoft. Более того, он с теми же целями вводит свою версионность. Впрочем ее Вы уже поспешено раскритиковали в пух и прах. Я Ораклист, а все же не думаю, что в microsoft не такие парни сидят, что не учесть тех мыслей, что Вы высказали.
23 май 05, 13:38    [1564133]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
StalkerS
Member

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

Я про то, что Вы скорее всего попытаетесь сказать, что в Оракле грязное чтение.

Это где там в моем посте хоть раз написано слово Оракл ? Он здесь вообще не причем. Подозреваю, что у вас появилась какая-то фобия, в каждом моем слове видите нападки на него.
vadiminfo

Меня удивляет тока то, что Вы верите, что так легко можно опровергнуть общепризннанные факты.

какие собственно общепризнанные факты я пытался легко опровергнуть ?
vadiminfo

Поэтому далее Ваши рассуждения про грязное чтение относятся к нему же.

к кому-же ?
vadiminfo

Впрочем ее Вы уже поспешено раскритиковали в пух и прах.

КОГО ? версионность ? я ? раскритиковал ? ГДЕ ?
vadiminfo

Более того, он с теми же целями вводит свою версионность.

в принципе, если вы не в курсе, само по себе грязное чтение никуда из Yukon'a не делось, при блокировочном режиме работы им вполне можно пользоваться.
ну а версионность будет использоваться только в тех задачах, где нужна, и там грязное чтение отпадает за ненадобностью.
vadiminfo

Я Ораклист

я в курсе ;)
24 май 05, 18:07    [1568690]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
vadiminfo
Member

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

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

В теме фигурирут Оракл и Скуль. Скуль Вы критиковань ни за что не будете, поскольку Вы апологет оного. Значит путем нехитрых рассуждений получаем тот самый Оракл как потенциальный объект критики.)
Возможно, на самом деле Вы критиковали SergSuper. Но он ведь тоже на Вашей стороне за Скуль выступает? Зачем тада Вы его критикуете, када полно Ораклистов вокруг, нуждающихся в критике Скулистов?)

StalkerS

какие собственно общепризнанные факты я пытался легко опровергнуть ?


Ну, я про версионность Оракла. Она признана как недопускающая грязного чтения. Мне показалось, что Вы намекали, что это Оракл придумал свою версионность ни на что негодную. Если не так, то забираю свои слова обратно.
Был не внимателен. Жара.

StalkerS

к кому-же ?


К Скулю. Мы не можем пока точно установить ошибаются Ваши коллеги в логике работы Юкона или нет. Потому раз Вы их критикуете, то, возможно, это критика Юкона, если они правильно описали логику.

StalkerS

КОГО ? версионность ? я ? раскритиковал ? ГДЕ ?


Хорошо. Реализацию версионности у того или другого СУБД или представления о ней коллег Вы критиковали? Было дело?
Там были Ваши слова "Это фактически - грязное чтение. " Для механизма версиооности - это приговор. Я, наверное, ошибочно принял это на счет Оракла, помятуя о Ваших прежних постах. Теперь перечитал и вижу, что Вы там с Вашим коллегой по СУБД не соглашались. Это все-таки еще не привычно.

StalkerS

в принципе, если вы не в курсе, само по себе грязное чтение никуда из Yukon'a не делось, при блокировочном режиме работы им вполне можно пользоваться.
ну а версионность будет использоваться только в тех задачах, где нужна, и там грязное чтение отпадает за ненадобностью.

Благодаря Вам я уже давно знаю, это предположение. Однако, существует и другая версия поддержки двух моделей транзакций. Юкон еще не может положиться на свой механизм версионности или вообще она там празно себя будет пока являть и потому остается еще в большей степени блокировочником. Так например у Скуля 2000 есть отключение эскалации блокировок. Но ее мало кто включает, даже если блокировки достали окончательно.
Это всего лишь предположение, но требующее проверки временем.
24 май 05, 20:54    [1569114]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
Yo!!
Guest
автор
Так например у Скуля 2000 есть отключение эскалации блокировок. Но ее мало кто включает, даже если блокировки достали окончательно.


где, в sql2k ? как ?
24 май 05, 21:54    [1569172]     Ответить | Цитировать Сообщить модератору
 Re: Появление версионника в Yukon лишает Oracle всяких преимуществ!  [new]
vadiminfo
Member

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

где, в sql2k ? как ?

Что есть? читал не то на этом форуме, не то в каких-то статьях в инете по сравнению СУБД Оракл и Скуль. Причем возможно с Юконом, но там было примечание автора про MS SQL 2000. Возможно, даже в двух местах. Вроде с помощью какого-то, возможно, не документированного параметра. Но это включение, насколько я, понял может привести к значительным расходам ресурсов на поддержание инфы о блокировках. В общем, если бы не было проблем, то явно бы эскалацию отключили раз и на всегда.
24 май 05, 22:21    [1569192]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить