Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 24   вперед  Ctrl
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

pkarklin wrote:
> locky... Ну уж Вы то... О какой либо просадке производительности можно
> говорить только по сравнению с чем то. А пока для сравнения предлагается
> некая гипотетическая теблица updated, затраты на построение которой,
> опять же, чисто из теоретических умозаключений не берутся, почему то, в
> счет.
а... Ну да...
Там была странная просадка при использовании одновременно
inserted/deleted по сравнению с использованием только inserted.....
т.е. просадка, выходящая за тогдашнее понимание ситуации (даже учитывая
расходы на обращение к двум таблицам вместо одной и учитывая джойн таблиц).
насколько мы сейчас понимаем, запрос вида
update Order_details
	set total = i.quantity * 2.25
	FROM Order_details p INNER JOIN (inserted i INNER JOIN deleted d ON 
d.id =  i.id and d.quantity != i.quantity) ON p.id =  i.id
работал непропорционально долго по сравнению с запросом вида
update Order_details
	set total = i.quantity * 2.25
	FROM Order_details p INNER JOIN inserted i  ON p.id =  i.id
из-за того, что в исходной табличке Order_details поле
just_one_more_column varchar(max) было заполнено 100К текстом.

Posted via ActualForum NNTP Server 1.4

24 июл 07, 15:13    [4429343]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
softwarer
pkarklin
особенно когда каждой записи "другой таблицы" соответствует много записей в проверяемой.

Ээ.. это Вы все еще про join по первичному ключу?


24 июл 07, 15:15    [4429361]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Безусловно - коррелированный. НА счет "весь набор" не совсем правы. Как только найдется такая запись, дальнейшее сканирование бессмыслено.


Безусловно, но эта строка не попадет в результирующий набор
24 июл 07, 15:15    [4429366]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Это будет частный случай. В любом случаи left join с последующей проверкой на NOT NULL будет менее эффективнее, чем NOT EXISTS, за счет того, что сервер не "начитывает" данные для их дальнейшей проверки, а только проверяет факт наличия записей.


Я не против того, что он будет эффективнее, мне не нравится слово "в любом".
24 июл 07, 15:16    [4429373]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
Вспомните что MS SQL блокировочник и представьте что было бы если бы таблица блокировалась пока не закончится репликация


Уже не только блокировочник. И наверное это правильно.
Во всяком случае портацию проекта с Oracle для нас это сильно облегчило
24 июл 07, 15:19    [4429403]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
dmidek
Рад, что результат оказался для
Вас ожидаемым ...


По этому пункту вопросов нет, мы тут больше тушканчиков на острие иголочки считаем (которых нет). Пытаюсь проникнуть разумом в merge от MS SQL :(
24 июл 07, 15:22    [4429421]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Пытаюсь проникнуть разумом в merge от MS SQL :(


А с этим то какие проблемы?!
24 июл 07, 15:23    [4429438]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Эксперимент:
...


Ok убедили. Рад что с этим все хорошо.
Цитата из MSDN слегка не в тему (мне в общем пофигу first или last главное чтобы inserted относился именно к выполняемой операции)
24 июл 07, 15:26    [4429466]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Gluk (Kazan)
Пытаюсь проникнуть разумом в merge от MS SQL :(


А с этим то какие проблемы?!


только время на проникновение разумом :)
24 июл 07, 15:28    [4429476]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
pkarklin
Александр, мне кажется, что обсуждение сейчас скатится на второй круг.

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

pkarklin
Вполне логично, что обращение к двум таблицам будет дольше, чем обращение к одной. Причем невожно, что это таблицы inserted и deleted в триггере или просто другое таблицы бд. Не так ли?

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

pkarklin
Говоря о "заметно дольше", Вы опять, как мне кажется, подспудно подразумеваете наличие таблицы "updated".

Ну да, ссылаясь на результаты Ваших с Игорем экспериментов, я надеялся, что у вас есть таблица updated. Логично, черт возьми. Павел, я процитирую фразу, на которую Вы отвечаете:

softwarer
И Вы, и он доказывали, что обращение в триггере к inserted+deleted оказывается заметно дольше, нежели только к inserted.

Я уже привык к тому, что Вы... поспешны, но я не понимаю, как беседовать с человеком, который не обращает внимания на сказанное в той самой фразе, на которую вроде бы отвечает. Более того, даже если я пойму - не вижу в этом никакого смысла. Простите, но пока Вы не смените подход, я буду просто игнорировать Ваши сообщения.
24 июл 07, 15:31    [4429490]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
SergSuper
в любом случае надо какое-то соглашение

Я согласен с тем, что это не самый удачный момент. Оптимального решения назвать не готов (по крайней мере, пока в MSSQL не появится объектов/записей, которые позволят использовать синтаксис updated.new.field), но как мне представляется, и это вполне нормально. Никак не менее, нежели "inserted join deleted" (если отбросить то, что второе, возможно, Вам привычнее и уже не режет глаз).

SergSuper
Не очень хорошо будет выглядеть если есть уже поле "new_id".

SQL> select count(*) cnt_total, sum (case when column_name like 'NEW!_%' escape '!' then 1 else 0 end) cnt_new from all_tab_columns ;

 CNT_TOTAL    CNT_NEW
---------- ----------
     10738          5

SergSuper
Вспомните что MS SQL блокировочник и представьте что было бы если бы таблица блокировалась пока не закончится репликация

Использование лога для репликации меня не удивляет, но я не очень понимаю, как это связано с триггером. Удерживать блокировки на время работы триггера все равно нужно.
24 июл 07, 15:45    [4429589]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
drev
1. Вы не заметили одного нюанса в примере.

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

drev
2. Мы рассматриваем текущую реализацию получения inserted и deleted, потому что
у нас нет альтернативной. Вы её не представили.

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

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

Грубо передергиваете. Хорошо хоть смайликом прикрываться не стали.

"Не подобной, а другой, и не в MSSQL, а в Oracle, и не дачу, а двух тузов на мизере".

drev
уж представить схему , без имплементации Вам не составит труда, так?

Не составило.
24 июл 07, 15:48    [4429611]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
1. Вы не заметили одного нюанса в примере.

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

drev
2. Мы рассматриваем текущую реализацию получения inserted и deleted, потому что
у нас нет альтернативной. Вы её не представили.

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

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

Грубо передергиваете. Хорошо хоть смайликом прикрываться не стали.

"Не подобной, а другой, и не в MSSQL, а в Oracle, и не дачу, а двух тузов на мизере".

drev
уж представить схему , без имплементации Вам не составит труда, так?

Не составило.


Если Вас не затруднит - Вы не могли бы дать ссылку или copy-paste?
24 июл 07, 15:58    [4429685]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Логично... ну да, примерно по той же логике, что "на четырех колесах доберешься до места вдвое медленнее, чем на двух".


softwarer
Ну да, ссылаясь на результаты Ваших с Игорем экспериментов, я надеялся, что у вас есть таблица updated. Логично, черт возьми. Павел, я процитирую фразу, на которую Вы отвечаете:

И Вы, и он доказывали, что обращение в триггере к inserted+deleted оказывается заметно дольше, нежели только к inserted.


Помилуйте, Александр. Откуда же мне взять таблицу updated?!

Позволю себе обратить внимание на вашу формулировку:

softwarer
Нет. Выяснили, что у текущей реализации MSSQL есть странная просадка производительности, непонятно из-за чего.


В ответ на высказывание:

SergSuper
Вроде выяснили что с точки зрения реализации раздельные inserted и deleted лучше.


Т.е. обвиняя меня в "посешности", Вы сужаете свое высказывание о потере производительности только на примере inserted&deleted vs only inserted.

С таким же успехом, о чем я Вам и пытался сказать:

SergSuper
Вполне логично, что обращение к двум таблицам будет дольше, чем обращение к одной. Причем невожно, что это таблицы inserted и deleted в триггере или просто другое таблицы бд.


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

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

softwarer
Нет. Выяснили, что у текущей реализации MSSQL есть странная просадка производительности, непонятно из-за чего.


Вместо MS SQL может быть подставлена любая СУБД на выбор, ибо в любой другой СУБД обращение к двум таблицам идет "заметно дольше", чем к одной.
24 июл 07, 15:59    [4429696]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
drev
Если Вас не затруднит - Вы не могли бы дать ссылку или copy-paste?

Где-то вот отсюда по ответам - там было выяснение, что за два механизма Вы постулируете, как доставать только нужное и так далее.
24 июл 07, 16:05    [4429750]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Если Вас не затруднит - Вы не могли бы дать ссылку или copy-paste?

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



softwarer
"Чем inserted и deleted поотдельности". Но столько же, сколько они вместе взятые. Грубо говоря, для выполнения запроса


select * from updated

надо будет вытянуть, разместить и обработать ровно столько же информации, сколько и для выполнения запроса


select * from inserted join deleted


Т.е. исходной структурой данных у Вас будет текущая реализация лога SQL Server? Если нет, то что?
24 июл 07, 16:15    [4429817]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
pkarklin
Т.е. обвиняя меня в "посешности", Вы сужаете свое высказывание о потере производительности только на примере inserted&deleted vs only inserted.

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

Во-вторых: давайте договоримся, что все, что я пишу другим участникам форума не предназначено для Вас и Вам не стоит это читать. В письмах к Вам я адаптирую формулировки в соответствии с Вашими особыми реакциями, но я не делаю этого и не собираюсь делать в письмах, которые пишу кому-либо другому. Если хотите - читайте эти посты и пытайтесь найти в них нормальный, а не особый смысл. Не хотите - не читайте и не реагируйте.
24 июл 07, 16:20    [4429872]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Во-первых, простите, но я не в состоянии понять смысл этой фразы. Если она важна, будьте так любезны найти более очевидную формулировку.


Интересно, что в этой фразе неочевидного?!

softwarer
Во-вторых: давайте договоримся, что все, что я пишу другим участникам форума не предназначено для Вас и Вам не стоит это читать.


Ок. Договорились!!!
24 июл 07, 16:31    [4429981]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
drev
Т.е. исходной структурой данных у Вас будет текущая реализация лога SQL Server? Если нет, то что?

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

Далее, я не готов при имеющихся данных судить, что лучше - накапливать эти данные во время операции в каких-то структурах памяти либо перечитывать лог. Поэтому я не собираюсь оспаривать выбор Sybase/Microsoft и везде в этом обсуждении предполагал, что данные будут браться из лога.

По общей структуре - по тем цитатам и примерам, которые были приведены ранее - к текущей реализации лога претензий нет, вытащить из нее данные никто не мешает. Проблема отождествления версий мигрировавших строк - не знаю, решаема ли в текущей реализации лога, если нет - очевидно, решается незначительной доработкой. Называть все варианты "если структура такова и выполняются вот такие правила, то решаем так, если такова то так...." - не буду, уж простите, слишком много вариантов. Конечно, есть универсальные решения, типа "использовать сквозной идентификатор", но они будут неоптимальны с точки зрения размера информации в логе, поэтому нужно искать решение с учетом конкретного случая.
24 июл 07, 16:41    [4430060]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Yo.!
Guest
softwarer

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


не тащит mssql2к5 ничего из лога, все также как и в оракле из MVCC берется.

http://mgopinath.blogspot.com/2007/01/logical-tables-of-sql-server-inserted.html
24 июл 07, 17:14    [4430316]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
pkarklin
Интересно, что в этой фразе неочевидного?!

Cмысл.

Не хочется, если честно, расписывать семантические диаграммы... скажу так: если верно мое предположение о смысле, который Вы имели в виду, то у фразы просто неверная синтаксическая структура. Синтаксически же верная трактовка фразы является логически бессмысленным утверждением.
24 июл 07, 17:16    [4430334]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
softwarer

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


не тащит mssql2к5 ничего из лога, все также как и в оракле из MVCC берется.

http://mgopinath.blogspot.com/2007/01/logical-tables-of-sql-server-inserted.html


В 2005 алгоритм построения таблиц inserted и deleted триггеров изменился. Все мои "выкладки" касались версии до 2005.
24 июл 07, 17:18    [4430350]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Yo.!
не тащит mssql2к5 ничего из лога, все также как и в оракле из MVCC берется.

Забавно. Ну, собственно, тем более.
24 июл 07, 17:20    [4430361]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Yo.!
Guest
pkarklin

В 2005 алгоритм построения таблиц inserted и deleted триггеров изменился. Все мои "выкладки" касались версии до 2005.

тогда к чему были примеры из mssql2k8 на тему MERGE !? ну до черт с ним пусть будет прочесывание лога в mssql2k, но пля, объясните мне тупому как он умудряется оторвать головку от писания при нормальной нагрузке и по каким правилам он находит измененые мной строки в этом логе ? или он прочесывает с конца и до упора ? как он определяет упор ?
24 июл 07, 17:33    [4430456]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Yo.!

Ну это несложно. В логе должна идентифицироваться каждая транзакция - ее начало, конец и каждая операция. Следовательно, несложно как запомнить диапазон сканирования, так и например сканировать от конца и до маркера начала транзакции.
24 июл 07, 17:36    [4430481]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить