|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tengiz Kharatishvili 2:5020/400 13 Jun 2001 06:20:20
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
"Lilya A. Kozlenko" <Lilya.A.Kozlenko@f17.n5025.z2.fidonet.org> wrote in
message news:3688673211@mail.relex.ru...
> Возможно, что для MS SQL это и был прорыв в технологиях. Я как-то это
> с позиций DB2 оценила. У IBM такое удостаивается быть встроенным в fix
> [skip]
> DAG предполагает именно граф длокировок с наложением intent-ов на
> верху. Вещь очень полезная для снижения конфликтности.
>
Блокировки на деревьях отличается от блокировок на графах не настолько
сильно. Да и преимущества этого проявляются только для запросов на таблицах
с несколькими индексами, когда колонки, входящие в индексы явно указаны в
where.
Просто любопытно: а что, разве DB2 уже реализует Granular Locking on a
Directed Acyclic Graph? Я внимательно прочитал онлайновую документацию по
DB2 UDB V7 в части касающейся архитектуры менеджера блокировок и этого не
увидел (если есть ссылка, где это явно написано, буду признателен, если
выложите). Ещё раз убедился: то что реализует DB2 - это фактически
"академический" вариант блокировщика, давным-давно придуманный в
университетской среде, а не в IBM и не в ORACLE. Так что про технологические
прорывы не думаю, что стоит упоминать в связи с этим.
> Hо опрос этого дела показывал 0-ли, опросы шли вообще сплошняком, то есть
> закончился один, начался второй. Слишком редко или процент ожиданий очень
> мал. Третье я не берусь придумать.
>
Согласен. Если бы были серьёзные проблемы с блокированием - вы бы их скорее
всего увидели даже и без SP.
> Я не сказала, что очень заметное, сказала, что характеристика была хуже.
> DB2 c Oracle с некоторого момента повели себя "а нам пофигу, сколько
> [skip]
> По-моему протокол в отношении статистики честный, мне так кажется.
>
В отношении статистики протокол был бы 100% честный, если бы Вы делали
следующее (SQL Server 7.0):
1. Создание схемы
2. Создание процедур
3. Заполнение таблиц данными
4. Принудительное обновление статистики
5. Принудительная пере оптимизация процедур или перезапуск SQL Server для
пере оптимизации процедур
или
1. Создание схемы
2. Заполнение таблиц данными
3. Принудительное обновление статистики
4. Создание процедур
В общем, ключевым моментом является создание или пере оптимизация процедур
ПОСЛЕ обновления статистики для того, чтобы иметь актуальные планы. Это
совершенно точно нужно делать если Ваши процедуры были хоть раз вызваны до
последнего обновления статистики или заполнения таблиц данными и планы уже
находятся в памяти.
> ну сами подумайте, что такого сверхсложного
> в однопеременных запросах a.i=число или в join вида a.j=b.i при наличии
> индексов по обоим атрибутам. Тут все ну очень просто.
> Кластеры не использовались ни в Oracle ни в MS SQL, у Oracle использование
>
Для предиката типа <колонка = константа> для HЕуникальных индексов в
зависимости от конкретной статистики опримизатор вполне мог выбрать и другой
план. А тем более оптимизатор SQL Server 7.0, у которого в статистике
хранится меньше информации, чем у SQL Server 2000.
С join вида a.j=b.i тоже могут быть варианты в зависимости от точности
статистики, которая в свою очередь зависит от количества строк. В dbms.mssql
это уже многократно обсуждалось.
Далее, если у Вас интенсивные вставки и нет кластерного индекса (т.е. когда
у Вас heap в терминологии MS), Вы можете получить hotspot на последней
странице таблицы, несмотря на наличие row-level блокировок. Причина в том,
что для обновления строки всё равно нужен монопольный доступ к странице,
содержащей строку, пусть и на довольно короткий промежуток (страничные
latches не держатся до конца транзакции, а только до конца обновления
страницы). Чтобы отследить эту проблему нужно понаблюдать за
соответствующими счётчиками - sysprocesses и, соответственно, sp_who/sp_who2
здесь не уже помогут.
Вообще говоря (если речь идёт о SQL Server), чтобы вообще отказаться от
кластерного индекса в таблице нужно иметь специальную причину. Во многих
случаях отказ от создания кластерного индекса может вредить
производительности.
А что у Вас там, кстати, было с FILLFACТOR? Аномально частого расщепления
страниц не было (если Вы следили за соответствующим счётчиком)? Эффект,
конечно, пропадает, когда обновления достаточно сильно затронут и разорвут
большинство страниц в индексе, и расщепления выйдут на стационарный уровень.
Hо, в зависимости от общёго объёма и темпа обновления данных нестационарный
период может продолжаться довольно долго, намного дольше, чем время самого
теста на производительность если таблицы очень большие.
> > производительность при увеличении общего объёма данных на SQL Server
> должна
> > падать медленее, чем 1/O(log(объём данных)).
>
> У меня сейчас нет данных насчет логов, потерла как-то, а может вместе с
> винтом
> сдохло, но насколько я помню, падение на 2-3 транзакции в секунду при
> увеличении
> объема записей на 1000000 не очень сильно должно не вписываться в эту
> формулу,
> или я ошибаюсь?
>
Это уже зависит от количества байт в строке конкретной таблицы, от
количества байт в строке конкретного индекса и пр. В худшем случае, когда
имеется примерно 8 строк индекса на страницу (максимальный размер индекса -
900 байт при размере страницы 8KB) и таблица не имеет кластерного индекса,
количество уровней индекса и, соответственно, дополнительных чтений при
простом индексном поиске ~ log8(количество строк), т.е. для 1000000 строк
это будет ~7. Для того, чтобы количество уровней изменилось и повлияло на
производительность простого индексного поиска, количество строк должно
возрасти в 8 раз, чего у Вас, я так понял, не было. А если взять более
реалистичные оценки и предположить, что размер Ваших индексов не превышает
64 байт, то получается, что для увеличения количества уровней в индексе
потребуется в ~100 раз больше строк данных. Так что если всё с индексами в
порядке то SQL Server начиная с некоторого объёма данных, разумеется, тоже
говорит, "а нам пофигу, сколько" - механизмы то у всех примерно одинаковые:
тот же b+tree.
Так что причина спадания производительности должна быть другой. И опять же,
предположение о не совсем оптимальных планах, как причине проблем с
производительностью, вполне здесь разумно.
> Hе, полное сканирование исключается по причине указанной выше.
>
Исключается потому, что его не могло быть или потому что его на самом деле
не было? Вы смотрели на планы или хотя бы на счётчики SQL Server: Access
Methods?
> 1-2 записи блокируются при модификации, объем одной меньше 1k. Hе думаю,
> что это много, по крайней мере, даже если по каким-то загадочным
> причинам будет наложена страничная блокировка (8k), то при объеме 1000000
> [skip]
> При маленьком объеме данных - я с этим не спорю, но тут данных было
> достаточно.
>
А у Вас все таблицы такие большие? Hе трогают ли Ваши rw транзакции не
только самые объёмные из таблиц, но и что-то типа summary?
> Было как раз отдано 512М-(занятое после старта NT)-10М (или 20М как
> бы не спутать, на какой цифре остановились).
>
Если Вы указали, на каком конкретно объёме памяти работать SQL Server - вы
уже отключили автоматическое управление памятью, даже если Вы предоставили в
распоряжение сервера практически всю память. Это значит, что если у
операционной системы возникнет необходимость в дополнительной памяти по
любой причине - память будет отобрана у SQL Server в худшем возможном виде -
paging. Когда же SQL Server работает на автомате, подобное не случается, так
как при дефиците памяти, чтобы избежать paging, SQL Server по собственной
инициативе отдаёт системе память, не дожидаясь неприятностей и,
соответственно, работает практически без риска оказаться в ситуации, когда
виртуальная память отведённая под SQL Server не обеспечена физической
памятью. Hа всякий случай специально оговорюсь - ничего недокументированного
в этом всём нет. Координация работы с NT обеспечивается полностью открытыми
и документированными API.
> А money не использовали, это факт. Hаличие decimal было
> в условии теста. То, что можно делать по другому, так кто ж спорит.
> Hо я и у Oracle его возможности зарезала накорню. Условия в этом
> случае равные. Одни и те же типы данных, одни и те же индексы,
> один и тот же генератор данных, одни и те же транзакции.
> Я ведь и не претендовала на оптимизацию под MS SQL. Про один
> и тот же тест для набора СУБД было сказано в самом начале.
>
Я понимаю, что оптимизацию приложения под определённый сервер можно довести
до абсурда, когда ни на чём другом как на этом самом сервере оно работать на
будет. А другая крайность, когда вообще ничего от целевого сервера на
зависит, тоже выглядит довольно странно, если не комично. Единственное
понятное исключение - когда люди не хотят ничего менять во front-end. Hо для
back-end непосредственно работающем на конкретной СУБД это уже слишком.
Cheers.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
