|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Alex Mikhajlichenko 2:5020/400 20 Feb 2001 12:35:38 To : All Subject : Re: Re[6]: Проблема с большими таблицами --------------------------------------------------------------------------------
Hi, Vladimir Pavlikov!
19-Feb-01 16:53 Vladimir Pavlikov (pvv@soil.msu.ru) wrote :
> Твоя уверенность умиляет, но Оракл реально падает при исчерпании места на томе
И что, у всех падает? Версия, платформа, ресурсы?
> отката (либо при запрете его расширения, даже когда места навалом). При том,
> что для самой базы (на другом томе) могут быть свободны гиги.
"Если долго ломать что-нибудь, оно сломается". А не пробовали обеспечить
достаточно места для?
Или тебя удивляет, что место для файлов данных не может быть использовано
на расширения сегментов отката? Так и должно быть, не стращай народ.
> Т.е. в условиях,
> когда IB "цветет и пахнет"...
Думаю, на этом примере очень хорошо видна разница между идеологией Oracle
и Interbase.
Говорят, что правильно сформулированная задача - это наполовину решенная
задача. Hо тогда, как ни печально, чтобы правильно сформулировать задачу -
ее надо наполовину решить ;) Так вот, ставя задачу в Oracle, всегда полезно
знать ответ целиком ;)
Такие например вопросы, как размещение файлов
данных по устройствам, для обеспечения производительности и
отказоустойчивости, разнесение таблиц с учетом динамики роста,
определение размера и количества злополучных сегментов отката -
все эти вопросы желательно решить на этапе проектирования. Все последующие
проблемы - на совести проектировщика, так что хвастаться ими неприлично ж)
Это не хорошо и не плохо, просто это очень логично в системах Oracle,
где обьем базы - порядка обьема всего (всех) веников, так что любой
"авось" приведет или к переполнению устройств, или гуляющим
десяткам гигабайт за ваши деньги.
Думаю, вопрос о версионниках и блокировочниках уперся в различие
классов конкретных продуктов. Поэтому давайте не пеняйть на Oracle за его
монстровидность, а порадуемся за Interbase, который замечательно скрывает от
нас многие проблемы, действительно неважные в большинстве реальных случаев.
--
* Alexey Mikhajlichenko
Вначале было Слово , и Слово было два Байта. alex@rtax.sumy.ua
--- ifmail v.2.15dev5
* Origin: Regional Tax Administration (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/65131cb5baff.html, оценка из 5, голосов 10
|