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

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

P.S.: Кстати, присутствие всех данных в кэше может сыграть злую шутку именно тем, что сервер может выбирать перебор всей таблицы из памяти, а не чтение индекса с диска. Так что еще не известно, что хорошо, а что плохо.

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

Значит я ошибся, и подходы АСА и АСЕ тут расходятся...

up
http://infocenter.sybase.com/help/topic/com.sybase.dc20023_1251/html/optimizer/X25495.htm
http://infocenter.sybase.com/help/topic/com.sybase.dc20023_1251/html/optimizer/X33106.htm

Ну вот, собсно мои подозрения подтверждаются. Я мыслил логически, основываясь на том, что любая более-менее серьезная СУБД должна расчитывать стоимость выполнения запроса и выбирать план с наименьшей стоимостью. А стоимость, как известно, очень сильно зависит от I/O, и как следствие ее сложно подсчитать не зная и пренебрегая объемом нужных данных в кэше.

cherrex_Denслучай с маленькими таблицами не берем
Дело в том, что понятия "маленькой таблицы" для ЭВМ и СУБД не существует. Она оперирует сухими, безжизненными и оторванными от реальности цифрами. Любая мат.модель лишь приблизительно описывает поведение реальности. И именно основываясь на законах сравнения этих цифр оптимизатор и приходит к выводу, что выгоднее, а что нет. А вот в результате чего вдруг эти самые цифры стали плохо отражать реальность и модель расчета стоимости дает сбой, вот это и есть вопрос. Может переполнился счетчик какой-то внутренний и БОЛЬШАЯ таблица для оптимизатора превратилась в маленькую?! Вот он и решил перелопатить по-быстрому кэш. А может вдруг по какой-то причине стоимость I/O подскочила? И одна операция ввода-вывода стала стоить как футбольная комманда? Тут оптимизатор тоже совершенно честно выбрал путь наименьшего сопротивления. Либо статистика по данным испортилась, либо слишком неочевидный запрос для оптимизатора, либо... Гадать можно долго. Алгоритмы оптимизатора скрыты и для нас недоступны.
В таких случаях есть возможность:
1) Упростить/разбить/видоизменить запросы
2) Установить подсказки оптимизатору, если разработчик на 100% уверен в гарантированной работоспособности своих подсказок.

cherrex_DenЯ считаю что кэш данных, это достаточно динамично изменяемая штука. Если бы была такая зависимость существовала, то тогда отпадает надобность в процедурном (или стэйтмент) кэше!

Скорее всего, оптимизатор учитывает какую-то среднестатистическую информацию о наполненности кэша!
Если бы кэш был размером с ноготь мизинца, то неудивительно, что данные в нем не задерживаются и вымываются с завидным постоянством и скоростью. А если кэш немеряный?))
И поток запросов юзает одно и тоже массивное и теплое, лежащее сначала на диске, а потом и в кэше?

Могу ответственно заявить, что индексы не всегда быстрее и лучше. И с точки зрения оптимизатора, и с точки зрения практики.
При HASH перемножении двух больших множеств (больших - это значит соизмеримых с размером кэша), которые уже имеются в памяти конечный результат достигается быстрее, чем дерганье индекса (тут даже уже и не важно, есть индекс в кэше или нет). Проверено.

MasterZiv
Нет. Он вообще никакую информацию о наполненности кэша не
учитывает. В частности, ASE-шный оптимизатор уж точно (в смысле, я это
просто знаю) никак не зависит от текушей наполненности кэша. Он
вообще не думает о том, какой будет IO -- физический или логический. Он может только оценивать общий объём доступного для данного объекта
кэша (дефолтный или именованый кэш), размеры пулов ввода-вывода, и
то, как этот кэш будет заполняться в ходе выполнения данного запроса
при применении выбранных для его выполнения стратегий работы с кэшем.

Не спора ради, а из-за здорового любопытсва.

авторFactors examined during optimization
Query plans consist of retrieval tactics and an ordered set of execution steps to retrieve the data needed by the query. In developing query plans, the optimizer examines:

The size of each table in the query, both in rows and data pages, and the number of OAM and allocation pages that need to be read.

The indexes that exist on the tables and columns used in the query, the type of index, and the height, number of leaf pages, and cluster ratios for each index.

Whether the index covers the query, that is, whether the query can be satisfied by retrieving data from the index leaf pages without having to access the data pages. Adaptive Server can use indexes that cover queries, even if no where clauses are included in the query.

The density and distribution of keys in the indexes.

The size of the available data cache or caches, the size of I/O supported by the caches, and the cache strategy to be used.

The cost of physical and logical reads.

Join clauses and the best join order and join type, considering the costs and number of scans required for each join and the usefulness of indexes in limiting the I/O.

Whether building a worktable (an internal, temporary table) with an index on the join columns would be faster than repeated table scans if there are no useful indexes for the inner table in a join.

Whether the query contains a max or min aggregate that can use an index to find the value without scanning the table.

Whether the data or index pages will be needed repeatedly to satisfy a query such as a join or whether a fetch-and-discard strategy can be employed because the pages need to be scanned only once.

For each plan, the optimizer determines the total cost by computing the logical and physical I/Os. Adaptive Server then uses the cheapest plan.

Stored procedures and triggers are optimized when the object is first executed, and the query plan is stored in the procedure cache. If other users execute the same procedure while an unused copy of the plan resides in cache, the compiled query plan is copied in cache, rather than being recompiled.



авторBasic units of costing
When the optimizer estimates costs for the query, the two factors it considers are the cost of physical I/O, reading pages from disk, and the cost of logical I/O, finding pages in the data cache. The optimizer assigns 18 as the cost of a physical I/O and 2 as the cost of a logical I/O. These are relative units of cost and do not represent time units such as milliseconds or clock ticks. These units are used in the formulas in this chapter, with the physical I/O costs first, then the logical I/O costs. The total cost of accessing a table can be expressed as:

Cost = All physical IOs * 18 + All logical IOs * 2


Из выделенного можно понять, что сервер все-таки разделяет физические и логические IO. И более того, видно, что одно физическое по стоимости равно 9-ти логическим. Константно и не поддается пересчету.
Вопрос, а зачем он разделяет операции ввода-вывода? Если думать логически, то если он не учитывает информацию о наличии данных в кэше, считает подефолту все необходимые данные находящимися на диске и не использует никакую статистику по данным в памяти, то зачем ему логические операции ввода-вывода? Получается в каких-то случаях он ее использует. При построении временных и рабочих таблиц, таких же индексов? И прочих внутренних объектов для выполнения запроса? Возможно. Я код сервера не дизассемблировал, и потому утверждать однозначно не могу ни одно, ни другое. А без исходного алгоритма все превращается в теории разной степени достоверности. А может у меня в голове заблуждения, относительно толкования терминов physical/logical IO...

При построении плана по хранимым процедурам, АСЕ наверняка не использует статистику по памяти именно из-за того, что план ее выполнения он сохраняет и использует при дальнейших вызовах. В такой ситуации, конечно же, глупо учитывать наличие данных в кэше. Но если бы оптимизатор пересчитывал план каждый раз для каждого запроса, то идея учитывать положение требуемых страниц уже не кажется такой абсурдной. И по моему опыту могу сказать, что АСА занимается чем-то подобным, она ж всегда составляет план перед каждым запросом. Да и с точки зрения реализации это не так уж и сложно. При размере страницы в 8К и размере требуемого массива данных в 100М, кол-во страниц будет порядка 12 тысяч и размер таблицы с битовыми флажками по доступности этих страниц в кэше будет менее двух килобайт. Пробежаться циклом по двум килобайтам и проверить наличие - это не задача для современной техники. К тому же, подобные карты нахождения страниц, их грязности и необходимости скидывания на носитель и так существуют в СУБД.

MasterZiv
ASE тоже иногда составляет план перед каждым запросом, но очень сомневаюсь,
что ASA использует данные о текущей наполненности кэша для составления
планов. Я, ещё раз, очень сомневаюсь, что вообще какая-то СУБД так делает.


Точно говорю, и даже этим свойством я пользовался. Припоминаю одну ситуацию, когда было необходимо выполнить сложный запрос, среди таблиц была одна объемом под 100млн, другая около 3, ну и мелочь всякая. Вообще запрос был очень плохой и тяжелый, но делался он исключительно ограниченное количество раз и смысла перекраивать что-то не было, проще было подождать выполнения. Так вот, с пустым кэшем он честно хватал индексы и все-такое. Если же перед этим делать хитрый холостой запрос, в котором тупо перемножались таблицы и считалось количесвто записей в перемножении (select count(*) from t1,t2,t3), то очевидно для этого он накачивал таблицы через кэш (они туда влезали целиком и не вытеснялись). Так вот, после такого запроса план первоначального запроса менялся в корне, никаких индексов, одни hash join и прочее подобные соединения массивов. Если после выполнения хитрого запроса с перемножением таблиц и искусственным затягиванием их в кэш сделать сброс кэша (sa_flush_cache), то все возвращалось на круги своя, использование индексов и все-такое. Я долго исследовал эту ситуацию, и статистику перестраивал и сервер в единоличное пользование брал для тестов вывод только один: либо это некая фича/баг у оптимизатора, либо он реально оценивал наличие нужных страниц в кэше. Эксперименты делал на АСА9.