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

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

И, простите, что в этом варианте интересного? Я понимаю, что "думать" интереснее, чем "читать", но сравните с

что интересного в обновлении статистики в авторежиме в сравнении с обновлением по таймеру ? Может я конечно вечером неадекватно воспринимаю реальность, но предположим, что ваш любимый Оракл настроен обновлять ее раз сутки в 22 часа вечера. Теперь еще предположим, что имеется некая таблица, в которую в 22.01 дядя Вася внес много апдейтов, превратив статистику в кучу бесполезного мусора. Не ошибусь-ли я, предположив, что в течении 23 часов 59 минут (до следующего апдейта статистики) все запросы будут пользоваться бесполезной (а по сути уже вредоносной) статистикой ?
Даже интересно, как вы выходите из положения, может заставляете ее обновляться раз минуту или просто нанимаете еще одного администратора Оракл за $2000 который неотрывно смотрит на USER_TAB_MODIFICATIONS view (которая судя по вашей цитате еще и обновляется не сразу а в течении нескольких минут) ?
softwarer

В принципе на эту тему в документации еще много интересного - надеюсь, Вы простите, если я не буду зафлуживать форум. Я полагал, что хватит ссылки :(

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

Если же начинать меряться интересными вещами, то было бы любопытно узнать, как в MSSQL реализовано, например, следующее:

вообще-то я здесь и не собирался ничем меряться, а просто сказал, что в mssql движется в сторону использования интеллектуальных механизмов вместо дорогостоящих администраторов, но тут вот ASCRUS так замечательно уже по этому поводу высказался, что остается только снять шляпу, похлопать в ладоши и отойти в сторону
softwarer

Хм. Завидный оптимизм :)

выяснение того, являетесь-ли вы умнее группы работников Microsoft является флудом, но все-таки я не удержусь и скажу, что встречал на данном форуме (и не только) посты некого tchengiz (если не ошибаюсь), который является непосредственным разработчиком движка mssql. Так вот этот дядя производит очень серьезное впечатление, и если взять штук 20 подобных людей, то при всем уважении к вам - у вас остается мало шансов
28 июн 06, 21:19    [2823177]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
ЛП
2 VoDA
пример: есть таблица на 10 млн. строк (может и больше). простая - 2 int + 1 varchar (один инт - PK).
Идет Update второго столбца инт в соответствии со словарем. СУБД используется монопольно.

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

Т.е. база используется в single-user mode?
И в синг-юзер моде оно умудряется вешать десять миллионов блокировок от самого себя?
Забавно.

И при этом еще не срабатывает эскалация блокировок, о которой так долго говорили большевики? А почему?

Простите, а Вы случайно ничего "ручками" не подкручивали? :)
Отлично. через две страницы обсуждения аудитория наконец-то поняла глубинный смысл проблемы.

Именно не срабатывала эскалация блокировок.
Нет ручками не крутили, SQL server EE over Win 2k3 EE в дефолтовой установке (все с последними сервис-паками).

ЗЫ вот тут возможно ручки очень даже помогли бы
29 июн 06, 11:08    [2824475]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
StalkerS
что интересного в обновлении статистики в авторежиме в сравнении с обновлением по таймеру ?

Нет. Интересность в варианте "авторежима" я вижу и сам - сервер запросто может начать собирать статистику в момент пиковой нагрузки и тем доставить много радости пользователям (альтернатива - собирать статистику не по всей таблице, а по мелкому самплу, и соответственно собрать некорректную статистику).

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

Тут мы как раз подходим к теме статистики для временных таблиц, которую, если не ошибаюсь, Вы решили не раскрывать.

StalkerS
Даже интересно, как вы выходите из положения,

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

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

StalkerS
может заставляете ее обновляться раз минуту или просто нанимаете еще одного администратора Оракл за $2000 который неотрывно смотрит на USER_TAB_MODIFICATIONS view

Хм. Я восхищен умением mssql-щиков придумывать сначала несуществующие проблемы, а потом нетривиальные варианты их решения. Впрочем, если под "заставляете обновляться раз в минуту" Вы имеете в виду установку соответствующего интервала у job-а, то как вариант решения плохим админом вполне сойдет, ничего плохого не случится.

StalkerS
(которая судя по вашей цитате еще и обновляется не сразу а в течении нескольких минут) ?

Да, это минус. MSSQL, насколько я понимаю, в течение нескольких минут успеет пять раз пересобрать статистику по меняющейся таблице.

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

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

Коротко - я могу сказать, что из знакомства с вашими данными и некоего брожения по BOL у меня не сложилось впечатление, что MSSQL умеет в этой области нечто, чего я не видел в Oracle.

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

Я не имею отношения к модерированию данного форума.

StalkerS
вообще-то я здесь и не собирался ничем меряться,

Значит, не сложилось. Вы сказали, что MSSQL "проще и надежнее в обслуживании благодаря...."; после пары ответов от vadiminfo общим смыслом - все о чем Вы говорите, в Oracle есть - полезли копать, пытаясь найти нечто лучшее. Сначала - Вы думали, что отсутствует понятие устаревания статистики. Когда оказалось, что и оно есть - не остановились. Признаться, это напоминает поиск аргументов при заранее заданной цели.

StalkerS
флудом, но все-таки я не удержусь и скажу, что встречал на данном форуме (и не только) посты некого tchengiz (если не ошибаюсь)

https://www.sql.ru/forum/memberinfo.aspx?mid=4313
29 июн 06, 11:12    [2824506]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
VoDA
ЗЫ вот тут возможно ручки очень даже помогли бы

Во многих серверах есть оператор LOCK TABLE, которым можно повесить единственную шаред или эклюзивную блокировку на всю таблицу до завершения транзакции или же завершения сессии. Это экономит время и ресурсы и бывает выгодно при массовых обновлениях большого кол-ва записей. Однако не понимаю, зачем Вам какие то "ручки" в MSSQL, когда там есть аналог такого оператора - хинты TABLOCK и TABLOCKX, которые по идее делают тоже самое ?
29 июн 06, 11:19    [2824561]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
StalkerS
Member

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

Интересность в варианте "авторежима" я вижу и сам - сервер запросто может начать собирать статистику в момент пиковой нагрузки и тем доставить много радости пользователям

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

Тут мы как раз подходим к теме статистики для временных таблиц, которую, если не ошибаюсь, Вы решили не раскрывать.

вам-же Cha давал ссылки, я-то чего могу добавить ?
softwarer

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

и что с того, какая разница ? Вот вы softwarer пока так и не дали каких-то аргументов против автосбора статистики, а высказали несколько туманных мыслей, что вот мол в пиковую загрузку возможно сервер начнет заваливаться, хотя это абсолютно голословно, ибо ресурсы ушедшие на сбор статистики вполне могут компенсироваться более удачным планом.
Я-уж не говорю о том, что вообще-то никто и не мешает на mssql отрубить весь этот автосбор (хотя это не рекомендовано), если это доказано тестированием конкретной системы. Это написано и в BOL и у Кален Дилейни, но вот вы почему-то не желаете им верить. Вот позвольте узнать, если вы что-то прочитали у Кайта, вы тоже начинаете это критиковать, или все-таки Кайту доверяете ? Тогда откуда такое недоверие к людям, имеющим в мире SQL Server такое-же значение, как Кайт в Оракл ?
softwarer

Коротко - я могу сказать, что из знакомства с вашими данными и некоего брожения по BOL у меня не сложилось впечатление, что MSSQL умеет в этой области нечто, чего я не видел в Oracle.

я тогда тоже коротко - сбор статистики на mssql можно организовать как по таймеру (аналог Оракл), так и в авторежиме, что является рекомендованным подходом. В Оракл такого нету. Все еще не удалось развеять ваше впечатление ?
Тогда про авторегулировку памяти я лучше вообще помолчу.
softwarer

Сначала - Вы думали, что отсутствует понятие устаревания статистики

вот видите, вы даже посты мои невнимательно читаете, я говорил не про отсутствие такого понятия в Оракл, а про отсутствие автоматического апдейта статистики, что является мягко говоря разными вещами
softwarer

https://www.sql.ru/forum/memberinfo.aspx?mid=4313

нет, не он, вот кого я имел ввиду. Кроме того, он даже консультировал Merle (наверняка его знаете) по поводу некоторых моментов.
29 июн 06, 16:13    [2826704]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
StalkerS
Member

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

Кроме того, он даже консультировал Merle (наверняка его знаете) по поводу некоторых моментов

на сайте Merle (rsdn), там он тоже под этим ником появлялся
29 июн 06, 16:17    [2826737]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
Yo.!!
Guest
StalkerS

я тогда тоже коротко - сбор статистики на mssql можно организовать как по таймеру (аналог Оракл), так и в авторежиме, что является рекомендованным подходом. В Оракл такого нету. Все еще не удалось развеять ваше впечатление ?
Тогда про авторегулировку памяти я лучше вообще помолчу.

на счет оракла, неужели не понятно, что если бы это имело смысл то включили бы ? оракл собирает "автоматом" только если совсем нет статистики, ничто не мешало бы включить проверку на каждый запрос, (как уже говорилось оракл Monitoring tracks the approximate number of INSERTs, UPDATEs, and DELETEs for that table, as well as whether the table has been truncated, since the last time statistics were gathered.) но с такими расходоми это глупо. не удивительно, что мс занимает последние места во всех тестах.
в 10ке есть AWR, который каждый час (по дефолту) снимает снепшот с базы и смотрит не появились ли злобные SQL, если появились то автоматом ими займется ADDM, который кроме статистики учитывает еще тысячу вещей и тут же предложит solution. я не знаю можно ли просить ADDM автоматом выполнить солюшен, но мне это совершенно не нужно, майла вполне достаточно.
иначе я представляю, ADDM решил что статистика херовая и решил пересобрать ее по 100Gb табличке за одно перестроив десяток индексов и раз уж такая пьянка к тому побить на секции, а чо ? план же лучше будет ! вон и ADDM советует, а люди, ну че их же не выгоняют 10% ресурсов им же останется :)
29 июн 06, 17:00    [2827109]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
andy st
Member

Откуда:
Сообщений: 899
Yo.!!
StalkerS

я тогда тоже коротко - сбор статистики на mssql можно организовать как по таймеру (аналог Оракл), так и в авторежиме, что является рекомендованным подходом. В Оракл такого нету. Все еще не удалось развеять ваше впечатление ?
Тогда про авторегулировку памяти я лучше вообще помолчу.

на счет оракла, неужели не понятно, что если бы это имело смысл то включили бы ?

если бы имело смысл, то DB2, наверное, сделали бы версионником ;)
29 июн 06, 17:08    [2827174]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
Yo.!!
Guest
Вот хороший документик как там все происходит:
http://www.vldb.org/conf/2004/IND4P2.PDF

In Oracle 10g, the SQL tuning process has been
automated by introducing a new manageability feature
called Automatic SQL Tuning. This feature is designed
to work equally well for OLTP and Data Warehouse
workloads. Unlike existing tools, Automatic SQL
Tuning is performed in the database server by the Oracle
query optimizer itself, running in a special mode. When
running in this mode, the Oracle query optimizer is
referred to as the Automatic Tuning Optimizer.
It is important to point out that the Automatic Tuning
Optimizer is a natural extension of the Oracle query
optimizer. In fact, the goal for both modes of the
optimizer (i.e., regular optimization mode and tuning
mode) is to find the best possible execution plan for a
given SQL statement. The main difference is that the
Automatic Tuning Optimizer is allowed to run for a
much longer period of time, generally minutes versus a
sub-second during the regular optimization mode. The
Automatic Tuning Optimizer takes advantage of this
extra time to profile the SQL statement and validate the
statistics and estimates used in the process of building an
execution plan. In addition, the Automatic Tuning
Optimizer can also explore execution plans that are
outside the search space of the regular optimizer. This is
because these execution plans are only valid if some
external changes made by the DBA (e.g. create a new
index) or by the application developer (e.g. rewrite the
SQL statement, possibly into a semantically non-
equivalent form) are assumed. The Automatic Tuning
Optimizer uses this what-if capability for access path and
SQL structure analysis.
Among all the above aspects, SQL profiling is
probably the most novel one. The main goal of SQL
profiling is to build custom information (a SQL Profile)
for a given SQL statement to help the query optimizer
produce a better execution plan. SQL profiles are stored
persistently in the database and are transparently used
every time their associated SQL statements are
optimized. This new technology allows tuning SQL
statements without altering their text, a key advantage
for users of packaged applications. As such, SQL
profiling can be considered an integral part of the
optimization process. Given that it is a resource-intensive
process, we believe it works best when it is limited to a
subset of SQL statements, namely those that have the
highest impact on the system resources or whose
performance is most critical to the database application.
Except for SQL profiling, all other aspects of SQL
tuning require interaction with the end user (the DBA or
the application developer). As a result, the Automatic
SQL Tuning feature is exposed to the end user via an
advisor called the SQL Tuning Advisor. The SQL
Tuning Advisor takes one or more SQL statements, and
produces statement-specific tuning advices to help
produce well-tuned execution plans. Here, the term
—advisor“ should not confuse the reader. It is important
to remember that the SQL Tuning Advisor is neither a
tuning tool nor a utility but rather an Oracle server
interface that exposes a comprehensive tuning solution
implemented inside the Oracle optimizer.
29 июн 06, 17:28    [2827354]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
StalkerS
безусловно, пользователи будут намного радостнее, если сервер не полезет исправлять статистику, а попрет исполнять запросы по устаревшему плану.

Безусловно. Позволю себе переформулировать Вашу мысль: пользователи, счастливо и радостно работающие с таблицей, измененной на 9.95% (по сравнению с состоянием на момент сбора статистики) резко грустнеют и даже плачут, когда им приходится работать с таблицей, измененной на 10.05%. Грустнеют настолько, что имеет смысл тормознуть сервер и вернуть им улыбку на лица.

StalkerS
вам-же Cha давал ссылки, я-то чего могу добавить ?

Я уже сказал, чего я не нашел в этих ссылках. Итак, судя по Вашему ответу, этого и нет.

StalkerS
и что с того, какая разница ?

Да, безусловно никакой. Схема рассуждений: MSSQL лучше. Чем? Ну вот он умеет контролировать устаревание статистики. Ах, Oracle тоже умеет? Но MSSQL умеет делать это не по таймеру. Ах, Oracle тоже умеет не по таймеру? Ну и какая разница, MSSQL все равно лучше.

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

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

StalkerS
ибо ресурсы ушедшие на сбор статистики вполне могут компенсироваться более удачным планом.

Хм. Вы пробовали считать?

Итак, если я правильно понял процитированное Вами Microsoft, после серьезных размышлений решил, что 10% - та магическая цифра, по достижении которой выгода использования обновленной статистики становится очевидной (как менее выраженный вариант - точка оптимальности, то есть выгода использования новой статистики перевешивает стоимость ее повторного сбора). Допустим, таблица в эксплуатации два года, изменения равномерны, режим самый что ни на есть обычный - insert, несколько update-ов, delete-ов практически нет.

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

Ваше утверждение: несмотря на это, подождать несколько часов - неверно.

Неубедительно.

StalkerS
Я-уж не говорю о том, что вообще-то никто и не мешает на mssql отрубить весь этот автосбор (хотя это не рекомендовано),

И правильно не говорите. Потому что - если Вы забыли - Вы пытаетесь доказать, что MSSQL превосходит Oracle, и аргумент "не хуже" для доказательства этого утверждения никак не подходит.

StalkerS
Это написано и в BOL и у Кален Дилейни, но вот вы почему-то не желаете им верить.

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

StalkerS
Вот позвольте узнать, если вы что-то прочитали у Кайта, вы тоже начинаете это критиковать, или все-таки Кайту доверяете ?

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

StalkerS
Тогда откуда такое недоверие к людям, имеющим в мире SQL Server такое-же значение, как Кайт в Оракл ?

Из Вашей бурной фантазии.

StalkerS
я тогда тоже коротко - сбор статистики на mssql можно организовать как по таймеру (аналог Оракл), так и в авторежиме, что является рекомендованным подходом. В Оракл такого нету.

Ну что ж, продолжайте так думать. Только, пожалуйста, думайте про себя.

StalkerS
вот видите, вы даже посты мои невнимательно читаете, я говорил не про отсутствие такого понятия в Оракл, а про отсутствие автоматического апдейта статистики, что является мягко говоря разными вещами

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

StalkerS
Речь о том, что сервер сам, по определенному алгоритму, определяет, когда надо обновить статистику и обновляет ее, без участия человека вообще.


Дальше Вы конкретизировали, что понимаете под "без участия человека":

StalkerS
вот сравните с вариантом mssql:

Kalen Delaney
The statistics will be misleading if they were generated when the dispersion of data values was significantly different from what appears in the current data in the table. However, SQL Server detects whether statistics are not up-to-date, and by default it automatically updates them. ....


Ключевая мысль фразы - именно устаревание статистики и пересбор в этом случае.

Таким образом, Вы "думали" про отсутствие аналогичного алгоритма в Oracle. Я показал Вам, что аналогичный алгоритм присутствует, только более изощренный: если в MSSQL автосбор происходит при выполнении условия "превышение порога изменений", то в Oracle аналогичная операция происходит при выполнении условия "превышение порога изменений AND время низкой нагрузки на сервер".

StalkerS
нет, не он, вот кого я имел ввиду.

Буду иметь в виду. Общаться, если не ошибаюсь, не доводилось.

StalkerS
Кроме того, он даже консультировал Merle (наверняка его знаете) по поводу некоторых моментов.

Знаю.
30 июн 06, 10:46    [2829230]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
Калина
Member

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

Но быть умнее группы разработчиков Microsoft вы не можете при всем желании, и если они решили убрать ручные установки - так на то были веские причины, и осуждать это глупо

Ну да. конечно!
Когда из винды убрали командную строку нормальную, тоже было верно и , наверное, даже веские причины , а потом начали хвастаться, какой клевый shell будет в новой винде!
Какой из этих двух подходов был верным? Вывод - М$ тоже ошибается
30 июн 06, 16:23    [2831535]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
StalkerS
Member

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

не удивительно, что мс занимает последние места во всех тестах.

если смотреть результаты тестов вверх ногами - то да
softwarer

Безусловно. Позволю себе переформулировать Вашу мысль: пользователи, счастливо и радостно работающие с таблицей, измененной на 9.95% (по сравнению с состоянием на момент сбора статистики) резко грустнеют и даже плачут, когда им приходится работать с таблицей, измененной на 10.05%. Грустнеют настолько, что имеет смысл тормознуть сервер и вернуть им улыбку на лица.
...
Да, безусловно никакой. Схема рассуждений: MSSQL лучше. Чем? Ну вот он умеет контролировать устаревание статистики. Ах, Oracle тоже умеет? Но MSSQL умеет делать это не по таймеру. Ах, Oracle тоже умеет не по таймеру? Ну и какая разница, MSSQL все равно лучше.

Вы знаете, обычно ваши посты интересно и познавательно читать, однако иногда попадаются такие, на которые я просто не знаю что ответить, потому-что они не имеют вообще ничего общего с постами, на которые ссылаются, и не имеют никакой нижележащей логики. Вам не нравиться порог в 10% ? Странно, в Оракл (написано в вами данной ссылке) использует именно этот порог, что-бы считать статистику устаревшей. Наверно можно сделать вывод, что в Оракл этот порог правильный, а в mssql нет. Просто детский сад какой-то.
softwarer

Хм. Вы пробовали считать?

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

Допустим, таблица в эксплуатации два года, изменения равномерны, режим самый что ни на есть обычный - insert, несколько update-ов, delete-ов практически нет.

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

Ваше утверждение: несмотря на это, подождать несколько часов - неверно.

Неубедительно.

Полностью согласен. Совершенно верно, логично и правильно. Как, впрочем и обратная ситуация, которую вы видимо второпях забыли вписать, я исправлю ваше упущение:

/////////////////////////
Допустим, таблица в эксплуатации около 10 мин., изменения равномерны, режим самый что ни на есть обычный - insert, несколько update-ов, delete-ов практически нет.

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

Ваше утверждение: несмотря на это, подождать несколько часов - неверно.

Убедительно.
/////////////////////
softwarer

И правильно не говорите. Потому что - если Вы забыли - Вы пытаетесь доказать, что MSSQL превосходит Oracle, и аргумент "не хуже" для доказательства этого утверждения никак не подходит.

Вы опять не прочитали толком мой пост. Вы что, специально так делаете ? Я там писал, что mssql может как Оракл, но в дополнение к этому, может и автоматом. "Не хуже" тут вообще не причем.
softwarer

Таким образом, Вы "думали" про отсутствие аналогичного алгоритма в Oracle. Я показал Вам, что аналогичный алгоритм присутствует, только более изощренный: если в MSSQL автосбор происходит при выполнении условия "превышение порога изменений", то в Oracle аналогичная операция происходит при выполнении условия "превышение порога изменений AND время низкой нагрузки на сервер".

опять 25. Давайте по шагам: Читаем в вашей ссылке:
Oracle documentation

The recommended approach to gathering statistics is to allow Oracle to automatically gather the statistics. Oracle gathers statistics on all database objects automatically and maintains those statistics in a regularly-scheduled maintenance job.
...
The Scheduler runs this job when the maintenance window is opened
...
However, there are cases where automatic statistics gathering may not be adequate. Because the automatic statistics gathering runs during an overnight batch window, the statistics on tables which are significantly modified during the day may become stale. There are typically two types of such objects:

-Volatile tables that are being deleted or truncated and rebuilt during the course of the day.

-Objects which are the target of large bulk loads which add 10% or more to the object's total size.

For highly volatile tables, there are two approaches:

1) The statistics on these tables can be set to NULL. When Oracle encounters a table with no statistics, Oracle dynamically gathers the necessary statistics as part of query optimization
...
2)The statistics on these tables can be set to values that represent the typical state of the table.

Теперь давайте по-русски:

1)Имеется job, который отвечает за обновление статистики для объектов, у которых она устарела.
2)Он запускается по таймеру (при помощи некой утилиты maintenance window), рекомедуется настроить на запуск в моменты спада нагрузки (например ночью).
3) Есть "горячие" таблицы, которым данный подход противопоказан.
4) Эту ситацию разруливают двумя путями:
4.1) Устанавливают статистику в null, что заставляет Оракл перестраивать статистику при каждом обращении к таблице
4.2) Установить статистику в значение "средняя температура по больнице" и запретить ее изменять.

Я все правильно понял ? Если все верно, идем дальше.

Теперь смотрим на механизм mssql:

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

А теперь softwarer, забудьте что вы ораклоид, и начните думать логически. Ущербность подхода с обновлением по таймеру понятна (надеюсь), подход с "средней температурой" вообще глупо обсуждать, а обновление статистики при каждом обращении к таблице как раз и способно привести к грустным и плачущим юзерам, напрасно ожидающим ответа от сервера.
А теперь важное замечание: при правильном администрировании, расстановке правильных коэффициентов, правильном "тайминге" job'ов и пр. танцев с бубнами сервер будет работать вполне адекватно, что доказывают хорошие позиции Оракл в тестах tpc. Вот только в mssql все это работает вообще без какой-либо настройки со стороны человека (при включенном автомате разумеется), что облегчает сопровождение системы. Это и было смыслом моих первых постов, который вы видимо не уловили (скорее всего не захотели уловить)
30 июн 06, 19:04    [2832245]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
softwarer
StalkerS
Теперь еще предположим, что имеется некая таблица, в которую в 22.01 дядя Вася внес много апдейтов, превратив статистику в кучу бесполезного мусора.

Тут мы как раз подходим к теме статистики для временных таблиц, которую, если не ошибаюсь, Вы решили не раскрывать.

softwarer
StalkerS
вам-же Cha давал ссылки, я-то чего могу добавить ?
Я уже сказал, чего я не нашел в этих ссылках.
Не уловил контекста, можете расшифровать, что Вы там искали и не нашли ?
Калина
Ну да. конечно!
Когда из винды убрали командную строку нормальную, тоже было верно и , наверное, даже веские причины , а потом начали хвастаться, какой клевый shell будет в новой винде!
Когда это у нее убрали командную строку ? Начиная с Windows 3.1, не помню ни одной версии, где нельзя было бы использовать командную строку. Может просто не там искали ? И можно ссылочки, где кто-то хвастается "какой клевый shell будет в новой винде" ?
IMHO, у Вас явный дефект логики, как из
Калина
Какой из этих двух подходов был верным?
может следовать
Калина
Вывод - М$ тоже ошибается
?
Ошибаться могут все, это не имеет ни малейшего отношения к степени ума.
30 июн 06, 19:13    [2832274]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
vadiminfo
Member

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

1) Когда требуется извлечь данные из таблицы, происходит проверка на адекватность статистики, если она старая - ее обновляют.

Но если ее обновление занимает 40 минут к примеру, (если это ни какя-то грубая оценка), сколько тогда займет извлечение данных?
А в это время Ваш дядя Вася или как его там все вернят обратно, теперь новая статистика устареет?
Да и как происходит проверка на адекватность? Предватительной грубой оценкой или по таймеру? Типа устарела?
30 июн 06, 20:07    [2832395]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
vadiminfo
Да и как происходит проверка на адекватность?
Такая информация устроит ?
30 июн 06, 20:10    [2832399]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
StalkerS
Member

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

Но если ее обновление занимает 40 минут к примеру, (если это ни какя-то грубая оценка), сколько тогда займет извлечение данных?

BOL

The cost of this automatic statistical update is minimized by sampling the data, rather than analyzing all of it.

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

Да и как происходит проверка на адекватность? Предватительной грубой оценкой или по таймеру? Типа устарела?

SQL Server documentation

After a series of INSERT, DELETE and/or UPDATE queries are performed on a table, the statistics may not reflect the true data distribution in a given column or index. If the SQL Server query optimizer requires statistics for a particular column in a table that has undergone substantial update activity since the last time the statistics were created or updated, SQL Server automatically updates the statistics by sampling the column values (using auto update statistics). The statistics auto update is triggered by query optimization and involves only a subset of columns referred to in the query.

Кален Дилейни

The number of operations is tied to the size of the table and is usually something like 500 + 0.2 * (number of rows in the table). This means that the table must have at least 500 modification operations before statistics are updated during query optimization; for large tables, this threshold can be much larger.
30 июн 06, 23:01    [2832628]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
Yo.!!
Guest
StalkerS

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

офигенный подход :) т.е. берется всего лишь маленький кусочек и по нему гадается. при этом "халявщики" должны на каждый DML выяснять, а не пора ли к гадалке.
так, чо если "automatic statistical update is minimized by sampling the data" не угадал, то теперь в ближайшие пол года пока something like 500 + 0.2 * (number of rows in the table) не наступило планы будут строится с кривой статистикой ?
30 июн 06, 23:19    [2832656]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Yo.!!
планы будут строится с кривой статистикой ?

А не задумывались над тем, что статистику можно построить нормальную с первого раза или вообще без нее обойтись? По этой теме цитат еще не было.
1 июл 06, 00:45    [2832772]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
Yo.!!
т.е. берется всего лишь маленький кусочек и по нему гадается. при этом "халявщики" должны на каждый DML выяснять, а не пора ли к гадалке.
Т.е., в Oracle самплинг не используется ? Всегда только полная статистика ? Т.е., на больших таблицах может уходить много времени ? Или любая статистика считается в Oracle, в отличие от MSSQL, мгновенно ? И за то время, пока она собирается, она не может "испортится" ? И это
автор
The statistics on these tables can be set to values that represent the typical state of the table.
не является вариантом "гадалки" ?
Yo.!!
так, чо если "automatic statistical update is minimized by sampling the data" не угадал, то теперь в ближайшие пол года пока something like 500 + 0.2 * (number of rows in the table) не наступило планы будут строится с кривой статистикой ?
Если сервер не угадал со статистикой, то это станет заметно достаточно быстро. В этом случае никто не может помешать обновить статистику вручную.

P.S. Yo.!!, не надо понтов, ладно ? Будут внятные аргументы, welcome...
1 июл 06, 00:46    [2832775]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
iscrafm
А не задумывались над тем, что статистику можно построить нормальную с первого раза или вообще без нее обойтись? По этой теме цитат еще не было.
Извиняюсь, что вмешиваюсь.
1. В каком смысле нормальная статистика ?
2. Без статистики обойтись, конечно, можно, но при этом, IMHO, придется забыть о нормальном выполнении динамических запросов. SQL сервера станут похожи на Cache, т.е., придется жестко "зашивать" алгоритмы обработки данных.
1 июл 06, 00:57    [2832795]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
ChA, в начале 90-х делали проекты на субд под unix без статистик, планов и пр. На одной из выставок проводили эксперимент: отбор по сложным условиям в базе населения. База без статистик и планов выдавала результат за секунды, оракл с соседнего стенда на этой задаче разрешал пойти покурить. Алгоритмы жестко не зашивались, язык запросов QBE. Имхо, планы появились из ядер написанных в старых условиях и используемых в новых реалиях. Никто ядра конечно не будет переписывать. Но это мое имхо, пусть таким и останется. Внимательноо слежу за новыми игроками на рынке СУБД, интересно.
зы Не знаю как в Cache, не копал эту базу.
1 июл 06, 01:24    [2832858]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
Yo.!!
Guest
iscrafm

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

ага, я тоже бывало экзамены с первого раза сдавал и чо :) ? или ты хочешь сказать что мс изобрел безупречную гадалку которая по кусочку 100% угадывает ?

ChA
Т.е., в Oracle самплинг не используется ? Всегда только полная статистика ? Т.е., на больших таблицах может уходить много времени ? Или любая статистика считается в Oracle, в отличие от MSSQL, мгновенно ? И за то время, пока она собирается, она не может "испортится" ?

документик вы ниосилили, жаль ... ладно попробую в 2х словах: в 10g есть optimizer, у него есть доли секунды, чтоб построить план, он собирает статистику только если ее совсем нет, выяснять, правильная ли статистика не его задача, да и времени у него нет, за доли секунды не поспеть. дальше есть automatic sql turning, это чудо просматривает SQLи и начинает их оптимизировать в фоне, пытаясь найти план получше. у него уже есть туча времени поберибирать планы, как они называют what-if аналитика, за одно может проверить статистику и если она устарела то "auxiliary information is generated to compensate for staleness". а вот нормально, по полной собирает статистику джоб, который запускается раз в сутки (по дефолту, естественно можно сколько хочешь запускать).
так, что оракл в принципе тоже полагается на гадалку, но только в промежутках между джобами, хотя надо еще выяснить, что такое "auxiliary information is generated to compensate for staleness".

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

ого :) я ошарашен услышать такое из лагеря mssql.

iscrafm
ChA, в начале 90-х делали проекты на субд под unix без статистик, планов и пр.

не поверишь, в начале 90х и оракл был "без статистик" и был там rule-based optimizer, а сегодня db2 до сих пор предпочитает строить план во время компиляции запроса, т.е. 1 раз и на всю жизнь ...
1 июл 06, 01:42    [2832893]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
iscrafm
ChA, в начале 90-х делали проекты на субд под unix без статистик, планов и пр. На одной из выставок проводили эксперимент: отбор по сложным условиям в базе населения. База без статистик и планов выдавала результат за секунды, оракл с соседнего стенда на этой задаче разрешал пойти покурить. Алгоритмы жестко не зашивались, язык запросов QBE.
Предполагаю, что любой вменяемый FoxPro-шник сможет воспроизвести тот же самый эффект, поставив практически любую современную РСУБД на колени. Уверен, Вы понимаете, насколько это будет неадекватное сравнение.
Уже как-то приводил пример, лет 5 назад в одном журнале, типа PC Magazin, делали сравнение РСУБД. По их тестам, лучшим сервером оказался MySQL, особенно в плане быстродействия. Фигня, что он не поддерживал транзакций и прочей фурнитуры, которой обвешана любая уважающая себя РСУБД.
1 июл 06, 01:52    [2832905]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Yo.!!
или ты хочешь сказать что мс изобрел безупречную гадалку которая по кусочку 100% угадывает ?

я про мс не слова не сказал. Экзамен на внимательность не сдан!

Yo.!!
не поверишь, в начале 90х и оракл был "без статистик" и был там rule-based

Поверю, я еще достаточно хорошо помню какой был оракл в это время, делали нормальные проекты с oracle на sco (помнишь еще таких?). И что? А ты поверишь что статистики появились с появлением задач на которые ядра не рассчитывали?
1 июл 06, 01:53    [2832907]     Ответить | Цитировать Сообщить модератору
 Re: Сильные стороны MS SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
Yo.!!
документик вы ниосилили, жаль ...
Честно говоря, и не собирался, мог бы заметить, что никогда не пытался доказать, что Oracle хуже, а MSSQL лучше. Во всем есть свои плюсы и минусы. Если что-то хуже при прочих равных условиях, то какой смысл его использовать ? Неужели надо говорить эту банальщину ?
Yo.!!
хотя надо еще выяснить, что такое "auxiliary information is generated to compensate for staleness".
Выясняй, ради Бога, только мне это на данный момент совсем неинтересно. Уже вышел из того возраста, когда хаят продукт, ничего толком о нем не зная.
Yo.!!
услышать такое из лагеря mssql.
А в чем проблема ? Можешь вручную, можешь джобом, можешь оставить все на "автомате", который достаточно неплохо работает, поэтому в массе своей никто не занимается первыми 2 вариантами.
1 июл 06, 02:11    [2832931]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить