Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13   вперед  Ctrl
 Re: Система ЭОД - неудача или успех ?  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
ScareCrow
автор
Жесть, а ведь это не редкий случай.

у вас Оракел?


нет, MS SQL 2005
15 сен 10, 18:05    [9445631]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
тогда не переживайте.
15 сен 10, 18:07    [9445646]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ScareCrow
автор
select * from acc where code='70107810300001730701' or code is null

дык о Оракела null не индексируется. поэтому этотт запрос пойдет по индексу только с извратами.
дык в таблице даже значения null нет, можно по статистике было бы проанализировать
15 сен 10, 18:08    [9445663]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
ScareCrow
тогда не переживайте.


я знаю, просто удивительно что Оракл такое пропустил. Хотя кто его знает, может в этом есть какой-то тайный смысл
15 сен 10, 18:10    [9445684]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
дык в таблице даже значения null нет, можно по статистике было бы проанализировать

попробуйте гистограммы собрать. по умолчанию они помоему не собираются.
15 сен 10, 18:12    [9445694]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Yo.!
Guest
SergSuper

например такой запрос
select * from acc where  code='70107810300001730701' or code is null
есть индекс по полю acc, но если есть or, то Оракл его не использует, а микрософт использует, иногда параллелит запрос
ну и с exists у оракла совсем плохо

ну ? коню ясно что если оракл нулы не индексирует то оптимайзер свалится в фулскан. мне понадобиться секунд 30 чтоб наложить function-based index и получить тот же план, что и в мсскл. экзист, обычно мне хватает 15 секунд чтоб понять чего тупит, да и обычно SQL advisor сразу говорит чего подкрутить.
еще раз, эти примеры никак не показывают как получить такой план на мсскл, который не возможно заполучить в оракле. а вот например с помощью оракловых кластеров (не путать с RAC) я получил запрос выполняемый в оракле на порядок быстрее
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=593514&pg=10&hl=%ef%eb%e0%ed#6329387

кстати там же можно полюбоваться как оптимайзер мсскл ступил трижды на элементарном запросе.
15 сен 10, 18:17    [9445727]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67529
Блог
SergSuper
дык в таблице даже значения null нет, можно по статистике было бы проанализировать

Можно, но есть одна маленькая проблемка. Дело в том, что строить план каждый раз, когда хочется выполнить запрос - довольно накладно. По этой причине у Оракла есть замечательная оптимизация: построенный план сохраняется в кэше и применяется для других, похожих запросов. В свете этого Ваше замечательное предложение вызовет неверную работу сервера в случае, если план построен и используется, а другая сессия возьмёт да и добавит в таблицу запись с null. Ну а инвалидировать кэш по каждому insert-у, знаете ли, немного дороговато будет.
15 сен 10, 18:28    [9445786]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
Господи, да на любой оптимизатор можно плохих примеров накидать. И на наш тоже :)
15 сен 10, 18:30    [9445793]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
Ну а инвалидировать кэш по каждому insert-у

скажите это сцуко MYSQL'ю. оно по каждому инсерту/апдейту кэш запросов (query cache) для учавствующих таблиц сбрасывает.
15 сен 10, 18:33    [9445807]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
softwarer,

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

Оптимизатору заменить бы OR на UNION ALL, но раз уж NULL не индексируется...
15 сен 10, 18:37    [9445827]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67529
Блог
iv_an_ru
но это и не требуется, кэшируемые статистики все равно достаточно грубы

Для реализации предложения Сергея - требуется. А грубость статистики зависит от того, когда и как она собиралась.

iv_an_ru
Оптимизатору заменить бы OR на UNION ALL,

В общем случае он такое делает, но в данном конкретном это не требуется и скорее вредно. Оракловый оптимизатор просто предполагает, что в тех редких случаях, когда подобный запрос имеет смысл, разработчик позаботится о его эффективном выполнении.
15 сен 10, 18:45    [9445876]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Favn
Member

Откуда:
Сообщений: 585
ScareCrow
дык о Оракела null не индексируется. поэтому этотт запрос пойдет по индексу только с извратами.
Люди добрые, это что - шутка была такая? Или про NULL - правда?
Никакие NULL, даже которые пустые строки? :)
Жесть какая-то...
15 сен 10, 19:40    [9446104]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Favn, В Оракле пустая строка конвертится в NULL... И да, NULL не индексируется. Можно обойти костылём в виде функционального индекса по nvl(nullable, 'ThisIsNull'), и искать по нему...
15 сен 10, 19:51    [9446149]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Vinny the POOH
Favn, В Оракле пустая строка конвертится в NULL... И да, NULL не индексируется. Можно обойти костылём в виде функционального индекса по nvl(nullable, 'ThisIsNull'), и искать по нему...

Чиво???? и найти все строки, в которых реально ThisIsNull? :)
15 сен 10, 20:26    [9446372]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
pkarklin
Member

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


Александр, полагаю, Вы в курсе, что такая же "замечательная оптимизация" есть и у MS SQL?!

Ниже перечислены ситуации, которые приводят к инвалидации плана в кэше:

-Changes made to a table or view referenced by the query (ALTER TABLE and ALTER VIEW).
-Changes to any indexes used by the execution plan.
-Updates on statistics used by the execution plan, generated either explicitly from a statement, such as UPDATE STATISTICS, or generated automatically.
-Dropping an index used by the execution plan.
-An explicit call to sp_recompile.
-Large numbers of changes to keys (generated by INSERT or DELETE statements from other users that modify a table referenced by the query).
-For tables with triggers, if the number of rows in the inserted or deleted tables grows significantly.
-Executing a stored procedure using the WITH RECOMPILE option.
15 сен 10, 22:35    [9446780]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!
SergSuper

например такой запрос
select * from acc where  code='70107810300001730701' or code is null
есть индекс по полю acc, но если есть or, то Оракл его не использует, а микрософт использует, иногда параллелит запрос
ну и с exists у оракла совсем плохо

ну ? коню ясно что если оракл нулы не индексирует то оптимайзер свалится в фулскан. мне понадобиться секунд 30 чтоб наложить function-based index и получить тот же план, что и в мсскл. экзист, обычно мне хватает 15 секунд чтоб понять чего тупит, да и обычно SQL advisor сразу говорит чего подкрутить.
да обычному человеку должно быть без разницы индексируются нулы или нет, есть запрос, а как он будет исполняться - придумывать function-based index, переделывать экзистсы - этим как раз и должен оптимизатор заниматься
даже если и можно переделать - иногда запрос с exists выглядит наглядней и если его надо переписывать потому что так оптимизатор не поймет - ну всё таки это недостаток оптимизатора, как ни крути
15 сен 10, 23:37    [9446984]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
pkarklin
softwarer
Дело в том, что строить план каждый раз, когда хочется выполнить запрос - довольно накладно. По этой причине у Оракла есть замечательная оптимизация: построенный план сохраняется в кэше и применяется для других, похожих запросов.


Александр, полагаю, Вы в курсе, что такая же "замечательная оптимизация" есть и у MS SQL?!

Ниже перечислены ситуации, которые приводят к инвалидации плана в кэше:

-Changes made to a table or view referenced by the query (ALTER TABLE and ALTER VIEW).
-Changes to any indexes used by the execution plan.
-Updates on statistics used by the execution plan, generated either explicitly from a statement, such as UPDATE STATISTICS, or generated automatically.
-Dropping an index used by the execution plan.
-An explicit call to sp_recompile.
-Large numbers of changes to keys (generated by INSERT or DELETE statements from other users that modify a table referenced by the query).
-For tables with triggers, if the number of rows in the inserted or deleted tables grows significantly.
-Executing a stored procedure using the WITH RECOMPILE option.
нет, здесь softwarer прав, вставка одной запись не вызовет инвалидации
15 сен 10, 23:40    [9446989]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Yo.!
Guest
locky

Чиво???? и найти все строки, в которых реально ThisIsNull? :)

мусье придуривается или оканчивал лишь трехмесячные курсы по бухгалтерии и потому так плохо представляет как работает NVL() ?

SergSuper

да обычному человеку должно быть без разницы индексируются нулы или нет, есть запрос, а как он будет исполняться - придумывать function-based index, переделывать экзистсы - этим как раз и должен оптимизатор заниматься
даже если и можно переделать - иногда запрос с exists выглядит наглядней и если его надо переписывать потому что так оптимизатор не поймет - ну всё таки это недостаток оптимизатора, как ни крути


обычному человеку нужно прочитать концептс и после этого проблем как минимум с нулами не будет. а вот бредятины, не описанной в мсдн в мсскл имхо много больше. когда count(*) возвращает нечетное значение на RC когда в таблицу только четное кол-во записей пишется, когда RC транзакция читает эксклюзивно заблокированную запись (из индекса) нарываясь на дедлок, когда оптимизатор тупит на банальном запросе пытаясь распаралелить чтение пару блоков. экзист ниразу не приходилось переписывать, у меня в 100% решалось созданием индеса статистика которого вправляла мозг оптимизатору.
еще раз, я вот показал элементарный запрос в мсскл где тупит оптимизатор, можете мне показать на столько же простой запрос в оракле, чтоб там так же тупил оптимизатор ? имхо оракловый мало того что много большему обучен и более сложно управляет статистикой, но и не тупит на столь элементарных запросах.
15 сен 10, 23:57    [9447025]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
iv_an_ru
Оптимизатору заменить бы OR на UNION ALL,

В общем случае он такое делает, но в данном конкретном это не требуется и скорее вредно. Оракловый оптимизатор просто предполагает, что в тех редких случаях, когда подобный запрос имеет смысл, разработчик позаботится о его эффективном выполнении.

ну я с этим столкнулся когда надо было две однотипные базы объединить в одну
если конкретно - банк работал каждым филиалом в своей базе, потом решил что база должна быть общая, сеть теперь позволяет
какие-то данные уже были и их надо было корректно привязать
т.е. если надо перенести клиента, то сначала он проверялся в базе приемнике по ФИО, дате рождения, адресу
каких-то атрибутов могло не быть(например даты рождения) и приходилось сравнивать с нулом и эти проверки заняли основную часть времени, в итоге мы уложились в поставленные сроки, но с трудом
т.е. да, задача была разовая, но с другой стороны намечается еще несколько таких банков и мне бы не помешал совет об эффективном выполнении
метод с function-based index использовать не хотелось бы - всё таки порядка 2000 таблиц, да если еще несколько полей... в основном конечно таблицы мелкие, но сейчас все работает автоматом, разбираться по каждой таблице не хотелось бы
16 сен 10, 00:07    [9447058]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
locky
Member

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

мусье придуривается или оканчивал лишь трехмесячные курсы по бухгалтерии и потому так плохо представляет как работает NVL() ?

чо будет если написать NVL('ThisIsNull','ThisIsNull')? Результат - какой?
16 сен 10, 00:56    [9447197]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Yo.!
Guest
locky
Yo.!

мусье придуривается или оканчивал лишь трехмесячные курсы по бухгалтерии и потому так плохо представляет как работает NVL() ?

чо будет если написать NVL('ThisIsNull','ThisIsNull')? Результат - какой?

syntax error
16 сен 10, 00:59    [9447213]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
locky
Member

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

мусье придуривается или оканчивал лишь трехмесячные курсы по бухгалтерии и потому так плохо представляет как работает NVL() ?

чо будет если написать NVL('ThisIsNull','ThisIsNull')? Результат - какой?

syntax error

Мусьё придуривается или
Как мусью ловко уходит от ответа, эта што-та!
16 сен 10, 01:07    [9447254]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
Yo.!
Guest
locky

Мусьё придуривается или
Как мусью ловко уходит от ответа, эта што-та!


where nvl(field1||field1,'ThisIsNull') = 'ThisIsNull'
на этом можно окончить с перфоменсом ?
16 сен 10, 01:17    [9447277]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
locky
Member

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

Мусьё придуривается или
Как мусью ловко уходит от ответа, эта што-та!


where nvl(field1||field1,'ThisIsNull') = 'ThisIsNull'
на этом можно окончить с перфоменсом ?

Вот за что мне всегда нравились ораклоиды - так это за то, как они изобретательно выпутываются из тех ситуаций, в которые другие прогеры просто не попадают.
Строят функциональные индексы по двойной ширине колонки например, мудрят с "магическими значениями" :)
16 сен 10, 01:41    [9447311]     Ответить | Цитировать Сообщить модератору
 Re: Система ЭОД - неудача или успех ?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
Yo.!
SQL Server 2005 introduces a new snapshot isolation level to enhance concurrency for OLTP applications. In earlier versions of SQL Server, concurrency was based solely on locking, which caused blocking and deadlocking problems for some applications. Snapshot isolation, by contrast, depends on enhancements to row versioning and is intended to improve performance by avoiding reader-writer blocking scenarios. ...
This non-blocking behavior also significantly reduces the likelihood of deadlocks for complex transactions.
http://msdn2.microsoft.com/en-us/library/tcbchxcb%28en-us,vs.80%29.aspx

собственно добавить нечего, версионность увеличивает конкурентный доступ за счет более эффективного использования ресурсов. можно сказать уникальный случай когда Yo! согласен с майкрософт.

а почему ссылка на msdn по Visual Studio-тo? Нормальные ссылки давать нужно, типа этой

Enable read committed isolation using row versioning when:
Reader/writer blocking occurs to the point that concurrency benefits outweigh increased overhead of creating and managing row versions.


чем ближе система к чистой oltp (писателей больше, читателей меньше) тем меньше присутствует Reader/writer blocking и тем меньше здесь нужна версионность
softwarer

Ну да, OLTP - это такая write-only система. Плодит данные, которые никому не нужны..
В OLAP писатель ровно чаще всего один и называется ETL. Запускается он в большинстве случаев редко и ночью, благодаря чему никому особо не мешает..
Судя по тому, что в OLAP читателей "много", а в OLTP, видимо, "мало", подразумевается, что в OLAP-системах пользователей на порядки больше

вам по сути та-же ссылка, что и Yo!, для ясности - чем меньше процент читателей, тем ненужнее версионность по очевидным причинам

softwarer

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

хорошо, не плодит, просто пишет во всякие undo\redo (или как они у вас там называются) блоки. Давайте зайдем с другой стороны, представим на секунду, что Ораклу больше не надо иметь такую функциональность, как доступ к предыдущим версиям строк (т.е. представьте, что вам необходимо сделать оракл для pure writing environment с нулевым или крайне незначительным числом читателей). Можно-ли оптимизировать теперь архитектуру Оракл (и как) с учетом этого?
16 сен 10, 04:53    [9447387]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить