Да, дискуссия получилась длинная…

В танном топике прозвучало несколько фамилий известных специалистов. Мне кажется, все-таки стоит дать некоторые комментарии.

Стива Адамса я бы назвал экстремалом в достижении рекордной производительности Oracle-систем. Достаточно хорошо зная детали функционирования Oracle он настраивает систему на достижение максимальной производительности исходя из ее целей и имеющихся возможностей. Его аудитория состоит в основном из профессиональных DBA, которых интересуют самые тонкие моменты в функционировании их баз данных.

Том Кайт все-таки более «попсовый автор», его аудитория – разработчики от начального до среднего уровня, которых обычно мало интересует, в какой момент времени DBWR сбрасывает на диск грязные буфера или сколько байт занимает одна строчка в ITL-таблице. Тем более охват его книг довольно широк и без определенных упрощений в данном случае тяжело обойтись. Детально описать затронутые темы в одной книге просто нереально, если конечно, автор не захочет сам попасть в книгу Гинесса.

Рама Велпури – известен среди DBA как специалист в области backup & recovery. К сожалению, русскоязычный перевод его с Адколи книги не поддается никакой критике, а англоязычного издания у меня нет. Анализом приведенных в книге скриптов я не занимался (т.к. обычно использую свои собственные), но общие сценарии восстановления (во всяком случае те, на которые я обратил внимания) вроде описаны корректно. Книгу эту я читал очень бегло, поэтому мог не обратить внимание на серьезные ляпы.


По поводу redo & commit уже практически все сказали Markelenkov с Ааз, Oracle newbie и Violina. Хотя, если вы настаиваете, «Фунтик» или кто-нибудь из DBGroup Consulting постарается поискать блох в этом опусе. Обещать точно не могу, уж больно много вы написали. Ребята сейчас все очень заняты, а я читаю медленно, практически по слогам, писать же вообще не могу

По поводу exp, rman, dbv, db_block_checksum и др .

Почему в этот список попал rman? Только потому что он регулярно запускается для своих целей и кроме всего прочего может ловить критические повреждения БД. Например, не далее, как в прошедшую пятницу при выполнении стандартного резервирования получаю:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03015: error occurred in stored script backup_al_all_disk
RMAN-03006: non-retryable error occurred during execution of command: backup
RMAN-07004: unhandled exception during command execution on channel d11
RMAN-10035: exception raised in RPC: ORA-19599: block number 24432 is corrupt in archived log F
:\ORACLE\ORADATA\TWR\ARCHIVE\4474.ARC
RMAN-10031: ORA-19583 occurred during call to DBMS_BACKUP_RESTORE.BACKUPPIECECREATE

Ради интереса чуть позже проверяю этот файлик с помощью alter system, естественно получаю те же яйца:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 24432 change 26653313 time 07/15/2004 18:38:46
ORA-00334: archived log: 'F:\ORACLE\ORADATA\TWR\ARCHIVE\4474.ARC'

Я не предлагаю вам rman в качестве панацеи от всех бед, я только говорю, что у него есть одна неплохая дополнительная особенность, которой иногда не грех воспользоваться. Если ваше приложение критично к ошибкам, установите кроме всего прочего db_block_checksum, время от времени запускайте dbv, почаще анализируйте alert.log (желательно, если это будет делать агент) и спите спокойно.


Ааз2. 2 "Fucker" тынц Пару моментов. a) dbv не может проверять файлы >2Gb.

Справедливости ради стоит заметить, что болезнью 31-го бита болели многие утилиты. Лень сейчас уточнять, но вроде это было много раньше. На металинке было много нот на эту тему тему, найти это не составит особых проблем.

Вот свеженький пример проверки на 8i четырехгигового файла:


Аазb) exp отдельно взятой схемы SYS в /dev/null чуток может помочь, но не затрагивает индексов по базовым таблицам словаря данных.

Ню-ню…

Экспорт отдельно взятой схемы sys не только «не затрагивает индексов по базовым таблицам словаря данных», он не затрагивает и сами базовые таблицы словаря . Точнее, затрагивает некоторое их количество косвенным образом во время своей работы.

В этом несложно убедиться по отсутствию такой вот строчки в log’е, при выполнении экспорта sys’овской схемы:
. about to export SYS's tables via Conventional Path ...
нет там такого, как и последующего списка экпортируемых таблиц. Например у его брата system’а такая строчка есть:
. about to export SYSTEM's tables via Conventional Path ...

А если подходить серьезно, можно оттрасировать эти две сессии , а потом сравнить, что и как в них делается… или реально открыть выходные файлы и посмотреть, что же реально экспортируется для sys’а.

Аазc) RMAN хреново тестирует (совсем не) только что импортнутые TTS. Надо их переводить в RW, потом опять в RO. Вся инфа на основе 8.1.7.4 и 9.2.0.5. До 10g-ки шаловливые ручки пока не дотянулись в желаемой степени.

Насчет tts ничего не могу сказать, я их не так часто использовал, надо пробовать…

АазPS. Ребятки, вы хоть понимаете, что уже накропали неплохую статью для Oramag? Недавно мне довелось побеседовать с Анатолием Бачиным (главред Oramag/ru). Он серьезно жалуется на отсутствие хороших материалов для публикаций. Слабо вам самоорганизоваться и заделать этот пробой? Про recovery должно получиться неплохо...

Сколько я его знаю, он всегда на это жаловался. В последнее время все меньше появляется там что-то интересненькое. Все больше лажи всякого рода, после прочтения которой которой так и тянет на использование нецензурных выражений. Почему-то сразу вспомнилось, как Володя Бегун высказывал свое мнение по поводу одной из таких статей, потом Павел Лузанов о другой. Самое интересное, что им так и не удалось доказать что-то авторам. Так что, если всерьез соберетесь что-то писать, постарайтесь выдержать соответствующий уровень, чтобы потом не краснеть и оправдываться.



Fucker

PS.: Почему я так «накинулся» на exp? Просто до сих пор некоторые товарищи строят всю свою политику резервирования (как показало данное обсуждение и не только резервирования) только на нем. Хотя с ростом объемов применимость утилиты экспорта значительно снижается. Я уж молчу о периодически появляющихся багах вроде Note:199416.1 ALERT: Client Program May Give Incorrect Query Results (EXP Can Produce Dump File with Corrupted Data)

Note: Oracle recommends that customers do not rely solely on EXP as a backup mechanism - customers are advised to always implement a proper physical backup strategy for databases.