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

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

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

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

выяснение того, являетесь-ли вы умнее группы работников Microsoft является флудом, но все-таки я не удержусь и скажу, что встречал на данном форуме (и не только) посты некого tchengiz (если не ошибаюсь), который является непосредственным разработчиком движка mssql. Так вот этот дядя производит очень серьезное впечатление, и если взять штук 20 подобных людей, то при всем уважении к вам - у вас остается мало шансов

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

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

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

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

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

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

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

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

на сайте Merle (rsdn), там он тоже под этим ником появлялся

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 все это работает вообще без какой-либо настройки со стороны человека (при включенном автомате разумеется), что облегчает сопровождение системы. Это и было смыслом моих первых постов, который вы видимо не уловили (скорее всего не захотели уловить)

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.