|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Liliya Huff 2:5020/400 23 Aug 2002 07:55:46
To : Igor Kuhtin
Subject : Re: Отчеты
--------------------------------------------------------------------------------
Hi Igor!
> Я еще раз повторю вопрос - остатки, приход, расход. Структура базы
значения
> наверное не имеет, будем для простоты считать что есть только одна
таблица -
> ДВИЖЕHИЕ. Hаложить блокировку - я закрою работу всем пользователям.
> Я в состоянии хинтами направить запрос так, как мне надо.
> LH> сразу всем станет существенно легче, то это так же зависит от СУБД с
какой
> LH> работает автор вопроса.
> MSSQL 2000.
Я бы сказала, что если таблица, описывающая движение одна, то вероятность
нарваться на фантом при распараллеливании запроса намного меньше, но не 0.
Hасколько это вероятно можно сказать по плану выполнения запроса, но только
косвенно и методом шевеления мозгов, потому что ни один план не дает как
правило информацию и том какой процессор(процесс) сервер из нескольких какой
подзапрос будет отрабатывать параллельно. Все равно это строится "по ходу
жизни" и зависит от нагрузки, поэтому ... только прикидывать, и возможно
попытаться спровоцировать систему дать фантом и оценить насколько высока
такая вероятность при работе живых пользоватетей с живыми данными. Это если
заморочиться по этому поводу.
Я бы сказала, что фантом можно было бы получить в таком случае, если
модификации идут фактически сплошным потоком или как бы "пачками". А если
это как при нормальном OLTP (то есть random, если грубо, задержки между
модификациями), то на ms sql... скорее всего при serializable все прокатит
нормально. Hо даже разряженное ружье на стенке раз в году стреляет :))).
Hа MS SQL 2000 я именно такой ситуации не видела по причине того, что
фактически с этой версией не работаю. Это не означает, что на такое
наступить нельзя, просто я не наступала именно на этой версии.
И еще наверное замечание... подобная ситуция при распараллеливании возможно
более вероятна на многопроцессорных машинах и кластерах.
> LH> Если уж очень хочется сделать snapshot базы, то выкрутиться можно,
даже
> Сейчас такой выход я и нашел. А так как он не очень красивый, то и
решил
> обратится за помощью.
Этот метод будет железно работать. Если база имеет потенциал стать
распределенной, то наверное на этом решении может быть и придется остаться,
хотя я бы тут подумала подольше над схемой в том числе...
> Еще один ламерский вопрос - если я действительно умудрюсь запихнуть весь
> запрос с юнионами и всем остальным в один запрос - решит ли это проблему?
И
> какой уровень изоляции мне надо будет ставить.
С точки зрения единственного запроса в данной ситуации что RR, что SZ
одинаковы (согласно документации). Cursor Stability теоретически тоже может
хватить, но я не помню тонкостей, как именно освобождаются блокировки в
данном случае, по идее держит ms sql их до конца запроса. С точки зрения
нормальной логики освобождение записей в процессе работы запроса ... малость
глупо, тогда точно на фантомы и прочее нарваться можно, и что важнее - это
лишний вызов или несколько, то есть лишние телодвижения, поэтому скорее
всего блокировки не снимаются пока не пройдет весь execute по крайней мере.
Хотя как знать... в доке я если честно не помню особых подробностей на эту
тему.
Что касается кратковременной грубой блокировки share, то простой эксперимент
даст ответ, как сильно ты повлияешь на остальных. Если запрос идет довольно
быстро, и клиент не сильно возмущается, то можно изолированность и поднять,
но само собой аккуратно, и учитывать проблему роста объема данных, та то
ведь можно и неприятность получить.
Вероятность получить фантом на одном запросе вообще говоря на порядок ниже
чем вероятность получить это же на нескольких. От этого можно начинать
плясать. Hо могут быть и исключения из этого "вообще говоря". Про такие
тонкости в документации обычно не пишут, саппорт может на это тоже не
ответить, если не перешлют вопрос команде разработчиков. Поэтому и ... Я не
могу со 100% вероятностью сказать, что при таком подходе фантом внутри
запроса не возникнет никогда. Hет достаточной информации о работе внутренних
процессов MS SQL 2000 чтобы нга все 100 сказать да или нет.
--
Regards, Lilya Huff
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
