su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Tengiz Kharatishvili                 2:5020/400     15 Jun 2001  07:33:28
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 "Lilya A. Kozlenko" <Lilya.A.Kozlenko@f17.n5025.z2.fidonet.org> wrote in
 message news:538463249@mail.relex.ru...
 
 > Они явно DAG нигде не пишут, но работает по Грею.
 > Ссылка на dag, например вот где (только книжка дорогая)
 > Gray J., Reuter A. Transaction Processing: Concepts and Techniques.
 > Corrected Second Printing, San Mateo, CA: Morgan Kaufmann Publishers,
 > Inc, 1993
 >
 
 Спасибо, у меня есть эта книга, как же без неё: это - Библия :). Я имел в
 виду ссылку на документ, где ясно написано, что у DB2 реализует MGL on DAG.
 Я посмотрел фирменную документацию по DB2 V2, V5 и V7, прочитал там всё о
 блокировках и Access Methods, и не нашёл нигде явного указания на DAG.
 Протоколы блокировок, в деталях описанные в Administration Guide и в
 Application Programmers Guide, являются просто MGL без DAG. Может, там не
 всё написано? Хотя, непохоже.
 
 > Похоже на то. А вообще момент не особо приятный получится. Так вот на
 > реальной системе будешь голову ломать. Теоретически такая штука могла
 > возникать в тесте, потому что каждая транзакция содержит insert в таблицу
 > истории операций со счетами. Если так, то торможение отсюда возможно.
 > ...
 > И похоже, что это объективный фактор, потому что ...  а как его убрать,
 > в отдельную транзакцию вынести - так это не поможет, latches-ы работают
 > ниже, чем транзакции, все равно будет кратковеременная блокировка.
 >
 
 Убрать это можно физически разделив поток строк от клиентов - делается это
 созданием кластерного индекса, первой колонкой которого будет какой-нибудь
 идентификатор пользователся, скажем, int у которого в качестве default стоит
 suser_id, или если Ваше приложение само ведёт список пользователей и
 указывает номер рабочего места / имя пользователся и пр. при вставке строки
 в таблицу истории операций со счётом, то тогда вообще ничего, кроме создания
 кластерного индекса по этой колоке и не нужно.
 
 Или ещё более простой вариант - кластерный индекс по номеру счёта и
 дате/номеру операции или что-нибудь в этом роде. Так как такой индекс
 полезен для агрегатных запросов по конкретному счёту, он у Вас и так,
 возможно, есть. В этом случае просто сделайте его кластерным. Правда, будьте
 осторожны - если у Вас много индексов на этой таблице, то их размер может
 заметно увеличиться, потому что все некластерные индексы строятся на основе
 кластерного и каждая строка некластерного индекса содержит кластерный ключ,
 по которому и идентифицируются строки в таблице с кластерным индексом. <Ух!
 сколько раз пришлось написать слово (не)кластерный :)>
 
 При этом вставки от разных пользователей или по разным счетам, по мере
 заполнения таблицы, будут всё чаще и чаще попадать в разные страницы заметно
 снижая вероятность нарваться на ожидание по latch, в пределе вообще доведя
 такую вероятность почти до нуля. Т.е. кратковременный захват страниц
 latch-ем, естественно, будет, но не будет конкуренции и, соответственно, не
 будет связанното с этим дополнительного ожидания - каждому клиенту будет
 нужна своя страница.
 
 > Sysprocesses в данном случае не отслеживался. А даже если бы и следили,
 > что бы это дало? Мне пока не ясно, как уходить от этого эффекта. Да и
 > так ли он страшен, если посмотреть объективно. При изменении страницы
 > ее и так и так блокировать будут, иначе, мы получим оптимистический
 > протокол работы со страницей, а в этом месте это вряд-ли выгодно.
 >
 
 Да, при изменении страницы её конечно всё равно блокируют, но не будет
 конфликта блокировок со стороны разных пользователей - всем нужны будут
 разые страницы.
 
 > Если страница сидит в памяти. А в исследуемой ситуации оно так и будет,
 > потому что транзакции идут быстро, записи короткие, даже если серверу
 > очень захочется последнюю страницу таблицы вытеснять, то это глупо,
 > к ней идут частые обращения хотя бы в течение некоторого интервала
 > времени, а потом они, то есть ображения, заканчиваются как только
 > создается новая страница, ведь update/delete не производится по странице
 > истории, а значит и процент перемещения данных по страницам равен 0.
 > Получается, что очевидных "ускорителей" в этом месте, по крайней мере,
 > не видно. Я что-то пропустила может быть?
 >
 
 Опять же, здесь дело не в вытеснении последней страницы а в конкуренции за
 неё.
 
 > > А что у Вас там, кстати, было с FILLFACТOR? Аномально частого
 
 расщепления
 
 > > страниц не было (если Вы следили за соответствующим счётчиком)? Эффект,
 >
 > Да нет, это может быть только тогда, когда идет update и значение
 
 изменяется
 
 > на большее по размеру (иначе нет смысла данные перемещать со страницы на
 > страницу), а там, где был update по таблице, там не было delete, стало
 
 быть
 
 > "дырки" не могли образоваться и слияния/ращепления, по крайней мере с ходу
 > не видно.
 >
 
 Всё правильно, но я имел в виду ещё и интенсивные вставки в таблицы с
 индесками. В общем, если ожидается высокий темп вставки и обновлений, то
 лучше заранее создавать некоторое разряжение в таблице, тем более, что в
 реальной жизни так почти всегда и бывает. Если Вы не меняли установок
 FILLFACTOR по умолчанию то для случая, когда все индексы созданы до
 заполнения таблиц данными, всё должно быть в порядке.
 
 Если же Вы сначала создаёте таблицы, заполняете их данными, а потом создаёте
 индексы - могут будут проблемы. Hо, так как заполнение таблиц и последующее
 создание индексов работает намного быстрее, для инициализации тестовых баз
 данных обычно именно так и делают. Если Вы тоже так делаете, то лучше при
 последующем создании индексов на интенсивно обновляемых таблицах явно
 указывать FILLFACTOR.
 
 Скажем, если Вы ожидаете, что во время теста у вас обновится или вставится
 примерно 10% данных от исходного объема большой таблицы, то значение
 FILLFACTOR 95% будет то что надо. С одной стороны, будет вполне реалистичная
 ситуация без слишком сильно искуственно заниженного темпа расщеплений, с
 другой - Вам не нужно будет много дополнительного места на диске (всего
 примерно +5%)
 
 См.
 http://msdn.microsoft.com/library/psdk/sql/ts_create_64l4.htm
 
 > Может быть. Разве у MS SQL индексы так плохо балансируются?
 > Ведь если подумать, то при расщеплении страницы блокируются только
 > 3 или максимум 4 страницы: текущая, которая разделяется, выделенная
 > новая и 1 или максимум 2 страницы уровнем выше по дереву, да и то не
 > полностью, хотя MS SQL в принципе имеет право блокировать страницы
 > ссылок целиком а не частично, кстати, тоячный протокол блокирования
 > физических страниц здесь известен? Я бы не сказала, что понимаю что
 > где и как в данном месте происходит полность. Скорее знаю, как должно
 > быть и как может быть и большой вероятностью, но точной ссылки привести
 > не могу. Есть такая?
 >
 
 Балансировку страниц индекса SQL Server совершенно обычным образом. Проблема
 с расщеплением не в количестве затронутых страниц - их не может быть много
 всегда, их много бывает только иногда - Вы, конечно, правы. Hо дело ещё в
 том, каждое расщепление это перемещение половины строк на другую страницу, а
 это довольно дорого с точки зрения CPU.
 
 Кроме того, операция выделения страницы требует дополнительных блокировок на
 allocation структурах, пусть и кратковременных, но значительно более
 подверженных конфликтам , так как такие структуры хранятся очень компактно и
 высока вероятность двум клиентам, которые реально по блокировкам на строкам
 не конфликтуют, нарваться на конфликт по latch для страницы в Index
 Allocation Map, например, если этим клиентам повезло вызвать расщепление
 страниц одновременно.
 
 По поводу точного протокола блокирования при расщеплении в SQL Server - мне
 не попадались подробные описания этого в Internet, в стандартной
 документации этого тоже нет, однако SQL Server делает это почти по
 учебнику - смотрите у того же Gray в главе 15.4 (B-Trees). Hекоторые
 сведения о физической архитектуре таблиц и индексов SQL Server можно найти в
 BOL:
 http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/sql/8_ar_da2
 _8sit.htm
 
 И вот это тоже может оказаться полезной ссылкой, масса мелких полезных
 советов по настройке производительности SQL Server и по поиску причин
 проблем с производительностью:
 http://www.sql-server-performance.com/
 
 См также:
 http://msdn.microsoft.com/library/techart/sqlqa.htm
 
 Cheers.
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

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