|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Vladimir Pavlikov 2:5020/400 20 Feb 2001 15:59:15 To : All Subject : Re: Re[8]: Проблема с большими таблицами -------------------------------------------------------------------------------- gaa8907s1v3@4ax.com> <3A8AA108.51F14A53@demo.ru> <96fjjl$nnt$1@service.katren.ru> <3A8BBDB7.6C64BB6C@demo.ru> <96gf8b$bsv$1@service.katren.ru> <3a8bc4d4.6418980@news.itfs.nsk.su> <96gkbl$913$1@host.talk.ru> <3A8BF48D.66D0A192@demo.ru> <96io4o$a3d$1@host.talk.ru> <3A8D080B.1059D033@demo.ru> <96j820$alg$1@host.talk.ru> <3a8d2e20.2675397@news.itfs.nsk.su> <96jepl$jg5$1@host.talk.ru> <96qt4j$rv3$2@host.talk.ru> <96rchn$s4h$1@host.talk.ru> <96rj0b$4ld$2@host.talk.ru> <96t56i$33b$1@host.talk.ru> From: "Vladimir Pavlikov" <pvv@soil.msu.ru> Hello! "Oleg Ivantchouk" <ion@utg.gazprom.ru> wrote: > VP> Hичего, никогда... Прочитай самую верхнюю строку, и попробуй описать > VP> действия сервера при необходимости сделать версию записи, входящей в > VP> резалтсет RR-тран- закции, при отсутствии на томе места для расширения > VP> отката... > Боюсь показаться назойливым, но позволю себе повториться еще раз. > Oracle все равно, входят изменяемые данные в резалтсет, или не входят. > Использование сегмента отката пишущей транзакцией производится точно также, > и от других сессий никак не зависит. Описание действий сервера см. ниже. И где ниже? Я просил последовательность действий, а не назойливые повторения. > VP> Твоя уверенность умиляет, но Оракл реально падает при исчерпании места на > VP> томе отката (либо при запрете его расширения, даже когда места навалом). > VP> При том, > Если поставить у тэйблспэйса с сегментом отката MAXSIZE UNLIMITED, то может > быть, не проверял. Предпочитаю MAXSIZE задавать вполне конкретный, не > выходящий за рамки тома. В таких условиях Oracle дает ошибку failed to extend > rollback segment, а никуда не падает. Еще раз - речь не о способах работы (описанных в доке), а о _классике_. Hет соображений на _этот_ счет? - "сливай", и закончим. > VP> что для самой базы (на другом томе) могут быть свободны гиги. Т.е. в > VP> условиях, когда IB "цветет и пахнет"... > Э-э-э, что это за отмазки - на другом томе? Если объемы информации, > генерируемые транзакцией, настолько большие, что диска не хватает, то лучшее, > что может сделать любой сервер - это выдать ошибку и вертать транзакцию взад. Пока твои тексты даже на отмазки не тянут. Я же тебе (да и сам ты тоже) демонст- рирую возможные (пусть даже и теоретически, хотя есть факты проблем на практике) проявления _недо_версионности. Твоей "классики"... Закончим. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/6488028c882b.html, оценка из 5, голосов 10
|