su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      31 May 2001  12:30:58
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 > Я не совсем понял Ваши расчёты размера изменений, которые идут в журнал -
 
 4
 
 4 страницы вот откуда: транзакция состоит из 5 операций, одна из которых
 производится над одной и той же записью, причем при update увеличения объема
 самой записи не происходит, следовательно на др. страницу она не
 "переползет".
 4 страницы будут подниматься в пул по максимуму, если все записи физически
 на разных страницах находятся, а если нет, то меньше. С размером 4k страницы
 - это опечатка, и Oracle и MS базы были сконфигурированы со страницами в 8k.
 Если все хорошо, то уже после 15-20 минут все  данные должны быть в памяти,
 а потому и ввод-вывод должен сводиться к минимуму, что собственно и было
 зарегистрировано посредством ms-ского монитора.
 
 > Вы уверены, что проблема была не в блокировках? Это может быть специфичная
 > для MS блокировка, раз уж Ваша задача нормально работала на другой DBMS на
 
 Блокирование исключается. MS не держит share на страницы до конца
 транзакции,
 а intent у нее просто нет, а serializable не был использован. Транзакции
 были
 подобраны так, что "подраться" на блокировках им было трудно. Вероятность
 блокировки не велика 2/1 000 000 и 2/10 000 000 именно столько данных было
 в основной таблице банковских счетов (2 - это как раз счета, задействованные
 при переводе денег). Пусть даже блокируется страница, ну сколько записей
 фичически моглотам быть, ну пусть даже 20 в 8k поместилось, все равно это не
 есть фактор,
 который мог бы существенно повлиять. Hе может получиться при таком раскладе
 линейное подение. Значит, причина скорее всего не в блокировании.
 Я даже на разные схемы (разные юзеры) разводила клиентов.
 Hо этот тест не слишком честный - ведь объем держать надо больший,
 а потому это так, в дополнение, и не больше.
 
 > Вариант: Вы работаете в transaction isolation level serializable, а
 
 Hе, такой высокий уровень не ставили, это слишком. Зачем перегружать
 структуру, обрабатывающую блокировки. Ведь в данном тесте не это меряется.
 
 > Если решение проблемы с линейным падением производительности для Вашего
 > приложения ещё актуально, свяжитесь со мной по email
 
 Это был просто тест, и не больше. А основная нагрузка на реальном приложении
 немного другая. Тут нас от MS SQL уводит отсутсвие, например,  connect by
 или его аналога (без временных таблиц или функций, иначе много кода
 переписывать, а это... в данном случае величина резко отрицательная).
 Есть и другие вопросы к MS SQL, но это разговор длинный, не думаю,
 что это надо в эхе затевать.
 
 > (tengiz.kharatishvili@gte.net) pls, чтобы не загромождать этим обсуждением
 > форум. Возможно, у меня есть некоторая полезная для Вас информация.
 
 Hаверное уже нет, просто проект ущел на Oracle окончательно, хотя
 вероятность портации на MS как на одну из платформ может рассматриваться,
 может быть в будущем, сейчас есть другое решение для дешевых систем,
 а для больших - там Oracle в качестве базы.
 Разве что просто интересно чисто теоретически, на случай каких-то других
 проектов, хотя не знаю, решусь ли я когда-нибудь что-то вроде билинга на
 MS SQL притащить.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

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