su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      18 Jun 2001  16:56:02
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net> wrote in message
 news:9gbvku$141d$1@ddt.demos.su...
 
 > Спасибо, у меня есть эта книга, как же без неё: это - Библия :). Я имел в
 
 Угу :)
 
 > Application Programmers Guide, являются просто MGL без DAG. Может, там не
 > всё написано? Хотя, непохоже.
 
 Видимо так, например есть ряд особенностей, которые не документированы,
 а из описанного в документации не очень следуют. Если интересно, можешь
 написать по e-mail, поговорим. У меня создалось впечатление, что все-таки
 без dag там дело не обошлось, иначе как они распараллеливают обработку
 одного запроса, хотя конечно могли и обычный multilevel transaction
 прикрутить
 и особенно сильно не заморачиваться.
 
 > Убрать это можно физически разделив поток строк от клиентов - делается это
 > созданием кластерного индекса, первой колонкой которого будет какой-нибудь
 
 [и т.п.... ]
 
 Знаю. Повторяю, в данном случае кластеры не использовались,
 можешь считать это внешним условием клиента, хотя по мне ... это конечно
 не особенно хорошо, но не всегда же поспоришь. Идея на тему кластеров
 в данном контексте мне нравится, хотя есть кое-какие моменты, но
 над ними надо немножко подумать, может это так ... померещилось...
 А что касается "выкручивания" схем, то я сперва начинаю смотреть
 физические параметры базы, потом парметры табличных пространств,
 потом индксы, кластеры, степень параллелизма обработки таблиц и
 индексов и т.п., а потом уже запросы. Такой порядок годится практически
 для любой СУБД, не без особенностей реализации каждо, как же без
 этого то...
 
 > реальной жизни так почти всегда и бывает. Если Вы не меняли установок
 > FILLFACTOR по умолчанию то для случая, когда все индексы созданы до
 > заполнения таблиц данными, всё должно быть в порядке.
 
 Hет, настройку по умолчанию в этом месте точно не меняли. Для Oracle
 я ее меняю всегда, потому что default у него дурной дальше некуда, а для
 MS SQL как-то и не нужно было. Индексы создаются после загрузки для
 рабочих таблиц, в таблице журнала индексов нет.
 
 > Балансировку страниц индекса SQL Server совершенно обычным образом.
 
 Проблема
 
 > с расщеплением не в количестве затронутых страниц - их не может быть много
 > всегда, их много бывает только иногда - Вы, конечно, правы. Hо дело ещё в
 > том, каждое расщепление это перемещение половины строк на другую страницу,
 
 а
 
 > это довольно дорого с точки зрения CPU.
 
 Hа эту тему информации по MS SQL нет, отследить-то трудно, хотя написать
 тест, который будет принуждать к расщеплению не сложно. Только  основная
 трудность - это чистота эксперимента, "процессор" выделить трудно в таком
 тесте. Поэтому я не берусь оценить тяжесть этой операции именно у MS SQL.
 По идее что там такого... Hайти адрес "где пилить", заголовок страницы
 откусывают по смещению, а дальше 2 memcpy (а по хорошему одно), ну взять
 еще у новой страницы старший элемент (чтоб на верхний уровень ссылку
 отдать), и пометить свободным "переехавшее" в старой, ну выделение новой
 страницы еще забыла... Хотя кто знает, что у них там в физике, может и не
 так
 все происходит. Код-то я не видела :)
 
 > Кроме того, операция выделения страницы требует дополнительных блокировок
 
 на
 
 > allocation структурах, пусть и кратковременных, но значительно более
 > подверженных конфликтам , так как такие структуры хранятся очень компактно
 
 и
 
 А вот это наверное зря, там видимо то что называют lock free можно
 реализовывать.
 Хотя чужой огород, может они и раздают ресурсы через "одну дырочку", вот
 чего достоверно не знаю, того не знаю.
 
 > высока вероятность двум клиентам, которые реально по блокировкам на
 
 строкам
 
 > не конфликтуют, нарваться на конфликт по latch для страницы в Index
 > Allocation Map, например, если этим клиентам повезло вызвать расщепление
 > страниц одновременно.
 
 Это как говорится ... попали так попали. Hо в принципе это не надолго,
 хотя...
 как сказать, если это место часто вызывается, там столько накопится, что...
 мало явно не покажется, приходилось мне видеть такие фокусы в коде :).
 
 > По поводу точного протокола блокирования при расщеплении в 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
 
 Это можно считать ничего, то есть дерево оно и есть дерево, чего мы там
 не видели :). То, что у них есть горизонтальные ссылки - это тоже момент
 очевидный (что они, будут на уровень вверх лезть, чтобы поднять следующую
 страницу индекса - не будут, потому что лишнее телодвижение, а это в данном
 месте совсем не хорошо). Вопрос в другом. Как, например, сама страница
 устроена, если есть упаковка данных, то какая и как работает, и что именно
 при обращении к странице блокируется - она сама целиком или ее заголовок,
 где служебная информация хранится, или есть оба протокола блокирования
 на низком уровне и т.д. То, что расщепление скорее всего жестко
 контролируется - в это я верю, а в то, что контроль может быть сведен к
 последовательному выделению страниц - ну может может бытьи такое , но
 насколько это так оценить не берусь, вообще говоря вещь достаточно
 багоопасная для переписывания. В документации по этому поводу кроме
 общих фраз естественно ничего нет, в общем-то такое содержание
 документации вполне логично.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

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