su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      14 Jun 2001  12:07:49
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net> wrote in message
 news:9g6ik7$2v4v$1@ddt.demos.su...
 
 > Просто любопытно: а что, разве DB2 уже реализует Granular Locking on a
 > Directed Acyclic Graph? Я внимательно прочитал онлайновую документацию по
 > DB2 UDB V7 в части касающейся архитектуры менеджера блокировок и этого не
 > увидел (если есть ссылка, где это явно написано, буду признателен, если
 > выложите). Ещё раз убедился: то что реализует DB2 - это фактически
 
 Они явно DAG нигде не пишут, но работает по Грею.
 Ссылка на dag, например вот где (только книжка дорогая)
 Gray J., Reuter A. Transaction Processing: Concepts and Techniques.
 Corrected Second Printing, San Mateo, CA: Morgan Kaufmann Publishers,
 Inc, 1993
 Я и говорю, что это хорошая реализация. А теория этого написано давно,
 в этом ничего особенного такого нет. MS сделал блокирование нормальным
 намного позже, у ibm-еров оно было лет десять назад, вот и все, правда
 не на всех платформах. У них, кстати  есть free locking, как водится
 аппаратная,
 если найду статью, то брошу по почте, у меня где-то был электронный вариант,
 мне реализация показалась интересной, живет только на манфреймах.
 
 > "академический" вариант блокировщика, давным-давно придуманный в
 > университетской среде, а не в IBM и не в ORACLE. Так что про
 
 технологические
 
 :) Можно посмотреть на имена :) все те же люди все там же, только сделали
 давно, а команда то была та самая старая, блокировщики стабилизировались
 вобщем-то достаточно давно.
 
 > Согласен. Если бы были серьёзные проблемы с блокированием - вы бы их
 
 скорее
 
 > всего увидели даже и без SP.
 
 Вот потому и не понятно, что же является причиной. Остается думать,
 что для данного типа задания имеет место что-то вроде предельной
 нагрузки.
 > В отношении статистики протокол был бы 100% честный, если бы Вы делали
 > следующее (SQL Server 7.0):
 >
 > 1. Создание схемы
 
 Имело место
 
 > 2. Создание процедур
 
 отсутствовало, так как sp не использовались и oracle
 
 > 3. Заполнение таблиц данными
 
 имело место
 
 > 4. Принудительное обновление статистики
 
 имело место (как и у Oracle)
 
 > 5. Принудительная пере оптимизация процедур или перезапуск SQL Server для
 > пере оптимизации процедур
 
 А вот это не оптимизировали, во первых в силу простоты запросов,
 во вторых и для Oracle такое не производилось.
 
 > В общем, ключевым моментом является создание или пере оптимизация процедур
 > ПОСЛЕ обновления статистики для того, чтобы иметь актуальные планы. Это
 > совершенно точно нужно делать если Ваши процедуры были хоть раз вызваны до
 > последнего обновления статистики или заполнения таблиц данными и планы уже
 > находятся в памяти.
 
 Модуль загрузки данных отдельный, после загрузки прогоняется обновление
 статистики, потом сам тест. Это с момента старта сервера. Или при прогоне
 теста повторно - рестарт сервера, обновление статистики, прогон теста.
 
 > Для предиката типа <колонка = константа> для HЕуникальных индексов в
 
 для primary key ему это вряд ли бы удалось, мне так кажется...
 Хэш точно не использовался, и у Oracle смотрели планы - тоже
 шло сканирование дерева.
 
 > Далее, если у Вас интенсивные вставки и нет кластерного индекса (т.е.
 
 когда
 
 > у Вас heap в терминологии MS), Вы можете получить hotspot на последней
 > странице таблицы, несмотря на наличие row-level блокировок. Причина в том,
 > что для обновления строки всё равно нужен монопольный доступ к странице,
 > содержащей строку, пусть и на довольно короткий промежуток (страничные
 > latches не держатся до конца транзакции, а только до конца обновления
 > страницы). Чтобы отследить эту проблему нужно понаблюдать за
 > соответствующими счётчиками - sysprocesses и, соответственно,
 
 sp_who/sp_who2
 
 > здесь не уже помогут.
 
 Похоже на то. А вообще момент не особо приятный получится. Так вот на
 реальной системе будешь голову ломать. Теоретически такая штука могла
 возникать в тесте, потому что каждая транзакция содержит insert в таблицу
 истории операций со счетами. Если так, то торможение отсюда возможно.
 И похоже, что это объективный фактор, потому что ...  а как его убрать,
 в отдельную транзакцию вынести - так это не поможет, latches-ы работают
 ниже, чем транзакции, все равно будет кратковеременная блокировка.
 Sysprocesses в данном случае не отслеживался. А даже если бы и следили,
 что бы это дало? Мне пока не ясно, как уходить от этого эффекта. Да и
 так ли он страшен, если посмотреть объективно. При изменении страницы
 ее и так и так блокировать будут, иначе, мы получим оптимистический
 протокол работы со страницей, а в этом месте это вряд-ли выгодно.
 Если страница сидит в памяти. А в исследуемой ситуации оно так и будет,
 потому что транзакции идут быстро, записи короткие, даже если серверу
 очень захочется последнюю страницу таблицы вытеснять, то это глупо,
 к ней идут частые обращения хотя бы в течение некоторого интервала
 времени, а потом они, то есть ображения, заканчиваются как только
 создается новая страница, ведь update/delete не производится по странице
 истории, а значит и процент перемещения данных по страницам равен 0.
 Получается, что очевидных "ускорителей" в этом месте, по крайней мере,
 не видно. Я что-то пропустила может быть?
 
 > Вообще говоря (если речь идёт о SQL Server), чтобы вообще отказаться от
 > кластерного индекса в таблице нужно иметь специальную причину. Во многих
 > случаях отказ от создания кластерного индекса может вредить
 > производительности.
 
 Согласна, в данном случае и в Oracle кластеры не использовались.
 
 > А что у Вас там, кстати, было с FILLFACТOR? Аномально частого расщепления
 > страниц не было (если Вы следили за соответствующим счётчиком)? Эффект,
 
 Да нет, это может быть только тогда, когда идет update и значение изменяется
 на большее по размеру (иначе нет смысла данные перемещать со страницы на
 страницу), а там, где был update по таблице, там не было delete, стало быть
 "дырки" не могли образоваться и слияния/ращепления, по крайней мере с ходу
 не видно.
 
 > конечно, пропадает, когда обновления достаточно сильно затронут и разорвут
 > большинство страниц в индексе, и расщепления выйдут на стационарный
 
 уровень.
 
 > Hо, в зависимости от общёго объёма и темпа обновления данных
 
 нестационарный
 
 > период может продолжаться довольно долго, намного дольше, чем время самого
 > теста на производительность если таблицы очень большие.
 
 Может быть. Разве у MS SQL индексы так плохо балансируются?
 Ведь если подумать, то при расщеплении страницы блокируются только
 3 или максимум 4 страницы: текущая, которая разделяется, выделенная
 новая и 1 или максимум 2 страницы уровнем выше по дереву, да и то не
 полностью, хотя MS SQL в принципе имеет право блокировать страницы
 ссылок целиком а не частично, кстати, тоячный протокол блокирования
 физических страниц здесь известен? Я бы не сказала, что понимаю что
 где и как в данном месте происходит полность. Скорее знаю, как должно
 быть и как может быть и большой вероятностью, но точной ссылки привести
 не могу. Есть такая?
 
 > Исключается потому, что его не могло быть или потому что его на самом деле
 > не было? Вы смотрели на планы или хотя бы на счётчики SQL Server: Access
 > Methods?
 
 :), может я не очень корректно выразилась, не было полного сканирования,
 и именно в планах. Я хотела сказать, что ms sql не совсем ненормальный,
 чтобы выбирать для указанного типа запроса полное сканирование. Может
 не так слова подобрала...
 
 > А у Вас все таблицы такие большие? Hе трогают ли Ваши rw транзакции не
 > только самые объёмные из таблиц, но и что-то типа summary?
 
 Hет :), summary считается один раз (в качестве процесса контроля)
 и после того, как все замеры завершены.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор