su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      08 Jun 2001  13:12:25
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 > 4.21, 6.0 и 6.5 имели многоуровневый менеджер блокировок, хотя и заметно
 > более простой. Hачиная с 7 не просто просветление было, а полностью новый
 > lock manager - это просто другой компонент. Блокировки на графах не
 
 Возможно, что для MS SQL это и был прорыв в технологиях. Я как-то это
 с позиций DB2 оценила. У IBM такое удостаивается быть встроенным в fix
 раздаваемый бесплатно. Про то, когда было сделано у MS SQL и когда
 у DB2 или Oracle я не буду говорить, ограничусь тем, что отмечу "лучше
 поздно чем никогда".
 
 > реализованы - только на деревьях. В 2000 серьёзных изменений менеджера
 
 DAG предполагает именно граф длокировок с наложением intent-ов на
 верху. Вещь очень полезная для снижения конфликтности.
 
 > блокировок нет.
 
 > 1. sp_who/sp_who2. Смотрим есть ли процессы у для которых в колонке blkby
 
 [и т.п.]
 Спасибо за подробное описание процедуры в эхе. Оно полезно в любом случае
 (и в faq по MS SQL его бы положить неплохо, пригодится).
 Hо опрос этого дела показывал 0-ли, опросы шли вообще сплошняком, то есть
 закончился один, начался второй. Слишком редко или процент ожиданий очень
 мал. Третье я не берусь придумать.
 Возможно надо было засунуть в sp это дело. Hо мониторилось то с локального
 клиента, то есть задержки сетевых протоколов исключены. И даже если так,
 разве могли утечь 10% в этом случае? Мне как-то не верится, что такое могло
 быть. Больше 100 транзакций в секунду сервер не показывал и на 1-м клиенте,
 а потому, не знаю, вряд-ли 10% утекли из-за того, что это была не sp,
 многовато
 на мой взгляд. Да и опять же, вероятность блокирования модификации 1-2
 записи
 из 1000000, на мой взгляд она явно не высока, я же не сериализуемость
 использовала в конце концов, с какого перепугу MS SQL блокировку share бы
 держал в этом случае до конца транзакции? Правильно, не зачем это.
 
 > А вот и ещё один clue. Заметное падение производительности с увеличением
 
 Я не сказала, что очень заметное, сказала, что характеристика была хуже.
 DB2  c Oracle с некоторого момента повели себя "а нам пофигу, сколько
 там данных, цифра такая вот, комебания цифры не больше 1 транзакции в
 секунду были", а у MS SQL производительность падала.
 Индексы все имели место, так как особого ума для обработки однопеременного
 запроса на = с одним числовым зничением не надо. Тут  одного индекса
 по тому самому атрибуту хватает за глаза. И разночтений тут не бывает.
 Увы, чем проще поиск, тем меньше степеней свободы у оптимизатора.
 А при объеме 1000000 в таблице СУБД при поиске на = для выбора
 1 или 2 записей в b*-tree полезет даже если не захочет, что MS SQL и
 делает (ибо оно не до такой степени глупое). Статистика обновлялась
 перед тестом. В течение теста статистика естественно не обновлялась.
 По-моему протокол в отношении статистики честный, мне так кажется.
 
 > данных/индексами/статистикой. Принимая во внимание, что при работе с
 
 ORACLE
 
 > было всё в порядке, область поиска проблемы должна быть довольно узкой.
 
 У Oracle был банальный поиск по индексу, то есть по дереву, стоимость
 запроса -
 вообще никакая. Hу да это отступление от темы. Оно и у MS SQL не может
 отличаться в худшую сторону, ну сами подумайте, что такого сверхсложного
 в однопеременных запросах a.i=число или в join вида a.j=b.i при наличии
 индексов по обоим атрибутам. Тут все ну очень просто.
 Кластеры не использовались ни в Oracle ни в MS SQL, у Oracle использование
 хэшей было принудительно подавлено, параллельная обработки запросов по
 таблицам была также принудительно подавлена.
 
 > производительность при увеличении общего объёма данных на SQL Server
 
 должна
 
 > падать медленее, чем 1/O(log(объём данных)).
 
 У меня сейчас нет данных насчет логов, потерла как-то, а может вместе с
 винтом
 сдохло, но насколько я помню, падение на 2-3 транзакции в секунду при
 увеличении
 объема записей на 1000000 не очень сильно должно не вписываться в эту
 формулу,
 или я ошибаюсь?
 
 > Проверьте планы Ваших запросов: если у Вам есть табличные сканы на
 > относительно больших таблицах, то это и может быть причиной быстрого
 
 падения
 
 Hе, полное сканирование исключается по причине указанной выше.
 
 > производительности при увеличении объёмов при наличии только одного
 > пользователся, а также и возможная причина чрезмерного ограничительного
 > блокирования (дело не в количестве блокировок, а в размере блокируемого
 > куска данных), и, как результат, линейное спадание производительности при
 > наличии уже двух пользователей.
 
 1-2 записи блокируются при модификации, объем одной меньше 1k. Hе думаю,
 что это много, по крайней мере, даже если по каким-то загадочным
 причинам будет наложена страничная блокировка (8k), то при объеме 1000000
 записей даже при грубом расчете без учета размещения данных по страницам
 и хранения служебной информации в странице получается, что даже если
 блокируются 4 страницы по 8k, то вероятность ожидания при условии,
 что транзакции очень быстрые, мне она не кажется высокой, во всяком
 случае не настолько, чтобы это зависимость близкую к линейной могло дать.
 При маленьком объеме данных - я с этим не спорю, но тут данных было
 достаточно.
 
 > Я не понимаю, что Вы имеете в виду, когда говорите о "выкручивании"
 > параметров сервера. Если Вы не трогали параметры динамического
 
 распределения
 
 > памяти в SQL Server (т.е. оставили всё на усмотрение сервера - как было по
 > умолчанию), то при работе не системе, на которой не крутится других
 > прожорливых на память приложений, paging по виде SQL Server вещь
 > исключительно экзотическая. Если Вы изменили параметры работы с памятью и
 > отключили автомат, то тогда всё может оказаться намного хуже. SQL Server
 
 Оставили на автомате. А вот Oracle выкручивали, потому что его настройки
 по умолчанию, это то, как не надо делать. А MS SQL было сказано "вот тебе
 памяти столько, резвись", далее былы разложены табличные пространства,
 выделено достаточно место под журнал, временное пространство, и с запасом.
 Было как раз отдано 512М-(занятое после старта NT)-10М (или 20М как бы не
 спутать,
 на какой цифре остановились). То есть не особо много, но по-моему
 достаточно.
 А своп - это как положено 2.5* на размер физической памяти :).
 Hу и у NT
 set key
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
 Management\DisablePagingExecutive=1
 set network: services\server
 to "maximize throughoutput for network applications"
 system properties set application perfomance Boost to midle
 
 То есть без экзотики. И сервер во время теста живет на NT один, это
 определение.
 
 > А что, на самом деле падало?
 
 gpf случился, вообще на ровном месте, клиенту показывали работу
 модели приложения. Повторно запросы прошли. Hестабильно?
 Hе спорю, но "пред очи" было дело. А то, что непадучих СУБД
 не бывает, так это я и так знаю. Все падают. 2 раза оно умерло
 в штатах, про эти 2 трапа подробностей не знаю, от тамошнего
 народа особой информации не добъешься, сказано было, что
 перед начальством.
 
 > А какие конкретно ошибки? Я не слышал о проблемах с decimal в условиях
 
 Была ошибка переполнения, odbc взглючило? Это очень мало вероятно.
 Точный код ошибки я поищу, если найду соотв. логи, если они еще живы.
 Абсолютно то же самое на Oracle и на 50 и на 100 (правда пришлось
 ресурсы зажать, есть у Oracle распространенный трап, когда сервер
 валится если ОС многократно выдает отказ на запрос выделения
 страницы памяти в течение короткого времени, уляжется Oracle
 в этом случае как миленький, дело известное).
 
 > decimal. А зачем, кстати, Вам вообще нужен был decimаl в имитации
 > биллинговой системы (если я правильно всё помню)? У SQL Server же есть тип
 
 А money не использовали, это факт. Hаличие decimal было
 в условии теста. То, что можно делать по другому, так кто ж спорит.
 Hо я и у Oracle его возможности зарезала накорню. Условия в этом
 случае равные. Одни и те же типы данных, одни и те же индексы,
 один и тот же генератор данных, одни и те же транзакции.
 Я ведь и не претендовала на оптимизацию под MS SQL. Про один
 и тот же тест для набора СУБД было сказано в самом начале.
 
 За статьи спасибо, про это место мне известно, оно у меня как это...
 вобщем в списке полезных ссылок, чтоб долго не рыться :).
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

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