Как загубить проект БД (часть 3)

Павел Шендрыгайлов, независимый эксперт

Oracle Magazine RE - Июнь 2002

Предисловие автора к части III: "К моему глубочайшему сожалению, я слишком поздно попытался внести небольшие изменения в текст второй части статьи. Поэтому добавлю буквально пару фраз.

В раздел, посвященный индексам, вкралась терминологическая неточность. Дело в том, что деревья индексов в Oracle всегда остаются сбалансированными, ухудшение же их характеристик происходит из-за "перекашивания" этого всегда "сбалансированного" дерева, а также из-за увеличения его глубины и размера. Это может заметно сказаться на скорости диапазонных сканирований индекса.

Когда мы говорили о необходимости периодического анализа объектов схемы, я совсем забыл о более мощном средстве - пакете DBMS_STATS, который обладает целым рядом функциональных преимуществ по сравнению с командой ANALYZE и не имеет недостатков, присущих этой команде."

С уважением,
Павел Шендрыгайлов.

---

[От редакции OMRE: первоначально эта статья была выложена на сайте Э.Шевцова, откуда наши читатели могут скачать весь ее текст полностью.]

---

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

А теперь я вам расскажу ужасную историю о том, как я попал в "край непуганых идиотов", говоря словами И. Ильфа.

Отсутствие грамотного администрирования. Или - три дня из жизни временно исполняющего обязанности нерадивого DBA.

На одном из мест работы мне иногда приходилось подменять отсутствующего администратора баз Oracle. Полное описание всех чудес, которые я встречал у него в базах перевесит, пожалуй, труды иных классиков. Поэтому приведу здесь наиболее показательные моменты и занятные несуразности.

Использование параметра PCTINCREASE для табличных пространств.

В один прекрасный момент на одной из промышленных БД у всех табличных пространств, кроме SYSTEM (и на том спасибо), значение параметра PCTINCREASE изменилось с 0 на 1. На мой недоуменный вопрос о причинах этого изменения администратор ответил, что вычитал этот совет в новой книге по настройке Oracle."50, как у SYSTEM по умолчанию, это много, а 1 - в самый раз, главное, что SMON будет просыпаться для сращивания свободных экстентов".

COALESCE по определению имеет смысл после операций DROP или TRUNCATE или DEALLOCATE UNUSED с ALTER TABLE или ALTER INDEX. В системе, которая функционировала на сервере, не было ни одного предложения такого рода. Естественно, что во время промышленной эксплуатации системы "не так часто" кто-либо выполняет такие операции. В базе данных разработчиков, само собой, это случается:иногда.

Не так давно я встретил вот такое высказывание Derry Kabcenel по поводу ненулевого PCTINCREASE для табличных пространств: "The wrong solution to a genuine problem". Мне кажется, коротко и ясно.

Когда я уже дописывал эту статью, я встретил еще более выразительную цитату на ту же тему: "Accumulated folk wisdom, which is not always correct. Over years, Database Administrators have collected their favorite space recipes and exchanged them. While some of these recipes are quite good, others are based on incorrect assumptions, or are plainly wrong. One example of the latter is setting PCTINCREASE to 1." [12]

Мне не раз задавали вопрос: "Если честно, то я не понял в чем трагедия использования PCTINCREASE=1? Неприятно да, но не настолько чтобы так переживать".

Трагедии, конечно, не случится, но Oracle часто изменяет запрашиваемое вами количество пространства, округляя его до "кусков по 5 блоков" и исходя из наличия непрерывных участков. В результате pctincrease = 1 вы можете получить большое количество совершенно разнородных по размеру экстентов.

Справедливости ради добавлю, что с появлением локально управляемых табличных пространств (locale-managed) решилось много проблем, связанных с управлением пространством. Еще один хороший кандидат для применения (Не используются UET$, FET$, единообразные размеры экстентов).

Табличное пространство TEMPORARY (в данном случае имеется ввиду НЕ перманентное) тоже имело значение PCTINCREASE, равное единице.

В тот раз разговор шел о версии Oracle 7.3, где временные сегменты могли создаваться или в перманентном, или во временном табличном пространстве. Если в перманентном пространстве дисковые сортировки приводят к множественным запросам на выделение и освобождение временных сегментов, то во временном пространстве обходится стандартный механизм управления пространством, что значительно снижает конкуренцию за space transaction очередь. Таким образом, если сегмент был выделен для какой-либо сортировки, нет никакого смысла его уничтожать после ее завершения, и он может быть использован для последующих сортировок.

Если ваши сортировки не умещаются в памяти и используют диск, установите PCTINCREASE=0 для временного табличного пространства. Другое значение в данном случае бессмысленно.

Связь между SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE.

Уже на другом сервере я увидел странную картину в V$PARAMETER:

db_block_size			4096
db_file_multiblock_read_count	90
--  незабыть бы, для чего привел.

Забыл! Наверно для того, чтобы акцентировать внимание на завышенное значение, которое заставило оптимизатор "увлекаться" full scan'ами. На том "сервере" была совсем "хилая", а точнее "никакая" дисковая подсистема (1 диск EIDE 30Gb).

[Прим. А.Бачина: одна физическая операция I/O максимально может оперировать с 64Кб данных. Из этого параметр db_file_multiblock_read_count обычно рассчитывается как (64К / db_block_size), чтобы при "панельном" сканировании таблицы/индекса можно было захватить максимальное количество данных за один оборот диска. Значение db_file_multiblock_read_count 90, безусловно, выглядит очень комично.]

sort_area_retained_size 4,194,304
sort_are_size   524,288

Понятно, что Oracle не сможет выполнить такое странное требование DBA. Сразу вспоминается квартира № 50 в доме № 392-бис по Садовой улице.

Формальное определение допустимого диапазона значений параметра SORT_AREA_RETAINED_SIZE из Oracle8i Reference: from the value equivalent of two database blocks to the value of SORT_AREA_SIZE

Реальный размер SORT_AREA_RETAINED_SIZE в данном случае будет равен SORT_AREA_SIZE или 524288, хотя представление V$PARAMETER покажет заданное в initSID.ora значение.

Раз уж мы занялись проблемой сортировок, следует еще раз взглянуть на параметры временного табличного пространства.

Tablespace Name	Initial Extent	Next Extent	Min Extents	Percent Increase
TEMP	65,536	65,536	1	0

В случае выполнения больших сортировок, требующих больше памяти, чем SORT_AREA_SIZE, маленькие умолчательные размеры экстентов приведут к перерасходу ресурсов на динамические расширения временных сегментов на диске.

Размер экстентов во временном табличном пространстве должен быть установлен в значение, кратное величине SORT_AREA_SIZE плюс дополнительный блок для заголовка сегмента. Это значит, что умолчательные INITIAL и NEXT параметры STORAGE должны быть равны этому значению, а PCTINCREASE соответственно должен быть равен нулю.

Контроль за состоянием "инвалидов" в БД.

В один прекрасный день наблюдаю странную картину в промышленной базе данных. Количество "объектов-инвалидов" в нашей базе данных превысило все мои ожидания, у нескольких пользователей (в том числе и у SYS) их набралось почти три сотни... На соседнем сервере чуть-чуть меньше.

Для борьбы с этой бедой необходимо периодически выполнять подобный запрос:

SELECT owner, object_type, object_name, timestamp, status
FROM dba_objects
WHERE status = 'INVALID'
ORDER BY owner, object_type, object_name

Если в результате окажется, что в базе есть объекты с ошибками, то для их перекомпиляции можно воспользоваться командой

ALTER PROCEDURE|FUNCTION|PACKAGE [<schema>.] <name> COMPILE [BODY]

или процедурой DBMS_DDL.ALTER_COMPILE.

Единственным исключением из этого правила будут синонимы. Когда что-то "случается" с объектом, статус его синонимов в DBA_OBJECTS по-прежнему VALID. Однако при попытке доступа к нему вы получите ORA-00980: Synonym translation is no longer valid. В этом случае следует удалить его, а затем пересоздать.

Если в ваших схемах много взаимозависимых объектов, может потребоваться несколько более "умный" подход. С несколькими подобными утилитами для перекомпиляции программ можно познакомиться на сайте фирмы RevealNet . Многие инструментальные средства также предоставляют эту возможность (например PL/SQL Developer фирмы Allround Automations).

Процессы и сессии.

С утра пораньше в управлении автоматизации телефон разрывается от звонков, администратора базы нет. Во время активной работы пользователей в конце месяца у некоторых пользователей появляется ошибка ORA-00020 maximum number of processes (100) exceeded. Новые пользователи не могут подсоединиться к системе.

В initSID.ora вижу такие строки:

session = 300
processes = 100		 - ???!!

Довольно оригинальный метод установки количества сессий, так как, если верить документации Oracle, session - зависимый от processes параметр (по умолчанию 1.1 * processes + 5) и его обычно не надо задавать в явном виде.

Добавляю требуемое количество процессов, уменьшаю sessions и пытаюсь перестартовать БД. На уровне ОС не хватает семафоров, администратора UNIX'а для изменения и перелинковки ядра тоже нет L . Приходится временно несколько умерить требования по количеству процессов и производить небольшие чистки неактивных пользователей.

Продолжение разговора о процессах и семафорах.

На некоторых UNIX-платформах доступен post-wait драйвер, исключающий использование семафоров, он обеспечивает те же самые функциональные возможности, но быстрее. Обратитесь к руководству по инсталляции и конфигурированию Oracle для вашей платформы, чтобы выяснить наличие этого механизма.

Попросите вашего UNIX-администратора сконфигурировать систему для использования этой возможности.

Чтобы Oracle использовал post-wait драйвер, необходимо добавить в файл параметров строку use_post_wait_driver = TRUE. После этого перезапустите базу данных.

После активизации post-wait драйвера воспользуйтесь командой ipcs -sb, чтобы убедиться, что Oracle не использует семафоры. В выводе команды не должно быть семафоров, принадлежащих владельцу Oracle.

/ > ipcs -sb
IPC status from /dev/kmem as of Tue Oct 30 17:03:07 2001
T     ID     KEY        MODE       OWNER    GROUP NSEMS
Semaphores:
/ >

Сегменты отката.

,b>Как говорят старые DBA, с rollback segments обычно бывает две беды:

• are my rollback segments properly sized;
• am I having contention for my rollbacks.

Несколько пользователей обратились с жалобами на периодическое возникновение появление ошибок во время работы системы. Выяснилось, что сбои происходили из-за невозможности расширения сегментов отката. Табличное пространство RBS было заполнено на 98%. У нескольких сегментов HIGH WATER MARK был около 100M при размере экстента 128k, ни у одного из сегментов не был установлен параметр OPTIMAL, что приводило к неконтролируемому их разрастанию. Не все приложения, производящие значительные изменения данных в БД, использовали SET TRANSACTION USE ROLLBACK SEGMENT big_segment.

Пришлось установить параметр OPTIMAL для всех сегментов.

ALTER ROLLBACK SEGMENT rbs01 STORAGE (OPTIMAL 2M);

А затем

ALTER ROLLBACK SEGMENT rbs01 SHRINK;

для приведения их текущих размеров в нормальное состояние.

На следующий день анализ V$ROLLSTAT показал, что после дня работы HWM основной части маленьких сегментов - 2121728 и количество SHRINKS около нуля. Т.е. значение OPTIMAL не было занижено.

Проанализировав результаты запроса к V$WAITSTAT, по наличию большого значения для 'undo header' был сделан вывод о наличии большой конкуренции за сегменты отката. Первоначальное действие - увеличить количество сегментов для поддержания существующего количества конкурирующих транзакций.

Размер и количество требуемых сегментов отката напрямую зависит от транзакционной активности вашей базы данных. Обычно для OLTP систем требуемое количество - один сегмент на четырех активных пользователей. Размер его экстентов подбирается опытным путем, так, чтобы при работе их количество находилось в переделах 10 - 40. Для больших пакетных заданий, выполняющих значительные по объему изменения, желательно использовать большие по размеру сегменты и лучше по одному на приложение (SET TRANSACTION USE ROLLLBACK SEGMENT). В системах с низкой активностью обновлений количество сегментов отката может быть меньше.

После более детального анализа ситуации выяснилось, что помимо нехватки сегментов было установлено некорректное значение для параметра TRANSACTIONS_PER_ROLLBACK_SEGMENT = 34. С помощью этого параметра и параметра TRANSACTIONS определяется количество сегментов отката, которое должна получить инстанция при открытии базы данных. Его значение по умолчанию равняется 5.

После создания дополнительных десяти сегментов и установки TRANSACTIONS_PER_ROLLBACK_SEGMENT = 4 конкуренция за возросшее количество сегментов отката, полученное инстанцией, снизилась до допустимого уровня.

День второй - "упала база"

Накануне вечером во время проведения cold backup "упала база", всю ночь DBA пытался ее "поднять", но все безуспешно. В результате он принимает решение - восстановить состояние двухдневной давности, так как авария произошла во время создания ежедневной холодной копии. Ради интереса наутро заглядываю в alert.log и вижу:

За три часа предпринято 12 настойчивых попыток открытия базы, которые завершаются совершенно одинаковым результатом. Только меняются имена trc-файлов.

Errors in file /sysdbs/dump/bkgd/dbwr_402.trc:
ORA-01157: ?????????? ???????????????? ???? ?????? 3 - ???? ?? ??????
ORA-01110: ???? ?????? 3: '/tmpdbs/tempA0.dbf'
ORA-07366: sfifi: ???????? ????, ???? ????? ???????? ???? ?????????.
ORA-1157 signalled during: alter database open...
SCO System V/386 Error: 2: No such file or directory

Что в "переводе" на английский означает:

ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: '/tmpdbs/tempA0.dbf '
ORA-07366: sfifi: invalid file, file does not have valid header block.

Когда я увидел этот файл (/tmpdbs/tempA0.dbf), уже трудно было сказать, оригинальный ли это файл или нет. Слишком много действий с ним было произведено. Никакого желания устанавливать это по датам создания или по SCNам у меня не было. Проверка файловой системы командой fsck показала отсутствие ошибок в нем с точки зрения ОС.

Поврежден файл временного табличного пространства. В принципе неприятно, но в такой ситуации нет ничего страшного. Временное табличное пространство не содержит объектов, критично важных для работы базы данных. Его можно безо всяких проблем пересоздать. Это можно выполнить за десять минут примерно такой последовательностью команд.

STARTUP NOMOUNT
ALTER DATABASE DATAFILE '/tmpdbs/tempA0.dbf' OFFLINE DROP;
ALTER DATABASE OPEN;
DROP TABLESPACE temp;
CREATE TABLESPACE temp DATAFILE '/tmpdbs/tempA0.dbf'
        SIZE ###M REUSE TEMPORARY;

Если вы не используете режим ARCHIVELOG, после частичного разрушения базы данных возможно два варианта дальнейших действий:

• восстановление с резервной копии (при этом вы теряете все изменения, произошедшие после резервирования);
• восстановить БД в поврежденном состоянии и затем удалить потерянные или поврежденные файлы данных.

При втором варианте используем ALTER DATABASE DATAFILE bad_file OFFLINE в смонтированной и неоткрытой БД. После этого можно открыть БД и оценить повреждения.

SELECT file_id, file_name FROM dba_data_files WHERE file_name = bad_file;

Затем, воспользовавшись полученным номером, можно выбрать экстенты, которые были размещены в испорченном файле:

SELECT owner, segment_name, segment_type FROM dba_extents
WHERE file_id = bad_id;

Если это индексы, ничего особенно страшного не случилось.

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

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

Повреждены временные сегменты - практически всегда можно восстановить данные, без каких бы то ни было проблем, связанных с целостностью данных. [13]

Приведенный выше пример наглядно показал полную несостоятельность примененной политики резервирования. Современный банк не может терять информацию за несколько суток. Для того чтобы этого не происходило, следует эксплуатировать базу данных в режиме ARCHIVELOG, разработать график выполнения процедур резервного копирования. Кроме регулярного выполнения горячего копирования желательно иногда делать и холодные копии. Для гарантирования целостности файлов базы данных можно использовать утилиту DBVERIFY. Иногда имеет смысл подумать о периодическом экспорте отдельных элементов схемы.

В качестве положительного примера реализации процедуры горячего бекапа можно использовать Sample Hot Backup Script (Note:30454.1) с http://metalink.oracle.com/. Очень показателен стиль обработки ошибок и охват всех возможных ситуаций.

Наличие четких, недвусмысленных инструкций, описывающих возможные варианты восстановления, является одним из основных критических факторов политики резервирования и восстановления. Естественно, перед вводом в эксплуатацию необходимо всесторонне протестировать весь комплекс используемых средств. Не так уж много времени потребуется на разработку подобного документа, но его наличие сильно поможет в критической ситуации. За основу я опятьпорекомендую взять документы, разработанные сотрудниками корпорации Oracle.[14, 15]

Backup без возможности Recovery.

В один прекрасный день после "успешного" выполнения режима холодного копирования не стартовала одна из промышленных баз данных. Дежурный администратор попытался ее стартовать вручную, но безуспешно. Как он мне потом объяснял: "Была какая-то ошибка ОС, но я не обратил внимания, какая L ". Вероятнее всего были проблемы с не освобожденной shared memory. Проанализировав журнальный файл, формируемый режимом архивации, и сравнив его с alert.log я понял, что нашу финансовую информацию, хранящуюся и обрабатывающуюся на сервере, спасла только надежность СУБД Oracle, которая терпит издевательства над ней в виде таких программ.

#
#	Регламентная процедура архивации файлов базы данных
#	$1 - file list for archiving
#         File format:
#         [#]<file_name>[: <file_name_arc>]
#	  where:
#		# - comments sign
#		file_name - file/catalog for tar, gzip
#		file_name_arc - archive name. m.b. ommit
#	$2 - archiving catalog
#	last modified:
#	03.04.2000, Doc
#	16.05.2001, Doc
#		добавлена отработка комментариев вида #..., пробелов
#
#	set local variables
ALIST=${1:-"alist"}
CNAME=${2:-"/jaz"}
ERRNO=0
#	shutdown DB server
su -l oracle -c svrmgrl > /dev/null <<EOF
connect internal
shutdown immediate
startup
shutdown normal
exit
EOF
if [ $? -eq 0 ]
then
    echo `date +%Y.%m.%d%n%H-%M-%S` ':' $0 ': server shutdowned'
else
    echo `date +%Y.%m.%d%n%H-%M-%S` ':' $0 ': ERROR. server not shutdown'
    ERRNO=1
    exit $ERRNO
fi
#	archiving DB files
cat $ALIST | while read i
do
  case $i in
  \#*)		# comments
      ;;
  *)
    SOURNAME=`echo $i | awk -F ":" '{print $1}'`
    DESTNAME=`echo $i | awk -F ":" '{print $2}' | awk -F " " '{print $1}'`
    if [ -z "$DESTNAME" ]
    then
      DESTNAME=`getfn $SOURNAME`
    fi
    tar cvf - $SOURNAME | gzip > $CNAME/$DESTNAME.tar.gz
  esac
done
#	startup server
su -l oracle -c svrmgrl > /dev/null <<EOF
connect internal
startup
exit
EOF
if [ $? -eq 0 ]
then
    echo `date +%Y.%m.%d%n%H-%M-%S` ':' $0 ': server startup'
else
    echo `date +%Y.%m.%d%n%H-%M-%S` ':' $0 ': ERROR. server not startup'
    ERRNO=1
fi
exit $ERRNO#

Весь режим архивации базы данных и прикладных систем запускался суперпользователем root, что уже само по себе нехорошо.

А теперь давайте попробуем выловить хотя бы половину "блох" из этого сценария. Первое, на что обращаешь внимание, это то, что список файлов БД, которые необходимо копировать, формируется администратором. DBA может забыть, что вчера он добавил еще один файл к табличному пространству или создал еще одну группу журналов повторения. В результате мы будем иметь совершенно бесполезный набор ничего не значащих файлов.

Выполнение пары, тройки запросов к V$DATAFILE, V$CONTROLFILE и V$LOGFILE не займет много времени, но позволит избежать катастрофических последствий. К полученным результатам можно будет добавить initSID.ora, файл паролей, конфигурационные файлы SQL*Net и т.д.

Любовь к команде su сыграла с автором скрипта злую шутку. Вместо того, чтобы контролировать ошибки выполнения SQL-команд, он интересуется результатом завершения su. А чтобы никто не разобрался в том, что реально происходило во время выполнения режима, весь выходной поток он предпочел отправить в /dev/null. Никому не нужны свидетели. Справедливости ради, отмечу, что и общий вызывающий скрипт отличался завидной молчаливостью, всю диагностику и текущие ошибки, на которые надо было оперативно реагировать, он не выдавал на экран, а писал в несколько различных файлов.

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

Наличие ошибок в выходном потоке безо всяких проблем можно было определить командой grep, поискав 'ORA-', а tee позволила бы продублировать информацию диагностики.

Ну и, наконец, последовательность команд, используемых в приведенном скрипте для останова базы, довольно бессмысленна. STARTUP без опций сделает базу данных доступной любому пользователю. И если кто-то успеет соединиться с ней до выполнения SHUTDOWN NORMAL, то, вероятно, этот останов так и не произойдет в ближайшем обозримом будущем. Для предотвращения этого необходимо использовать в STARTUP опцию RESTRICT, она ограничит возможность соединения для пользователей, не обладающих привилегией RESTRICTED SESSION. Если у вас используется параллельная опция, добавьте к этому и EXCLUSIVE.

Комбинация SHUTDOWN IMMEDIATE с SHUTDOWN NORMAL тоже довольно спорный момент. С одной стороны опция IMMEDIATE, скорее всего, вам не поможет быстро остановить базу с "подвисшим" job'ом, выполняющим распределенную транзакцию. А с другой - уже один даже SHUTDOWN IMMEDIATE оставляет базу данных в согласованном состоянии.

Так что более логичными были бы следующие возможные комбинации:

SHUTDOWN IMMEDIATE
или
STARTUP FORCE RESTRICT
SHUTDOWN NORMAL
или, наконец, просто
SHUTDOWN ABORT
STARTUP RESTRICT
SHUTDOWN NORMAL.

Самое примечательное, что обнаружились эти ошибки случайно, уже после увольнения с работы "бессмертного" автора процедур резервного копирования. К сожалению, такие случаи не так уж и редки L .

В заключение стоит вспомнить три основные зоны ответственности DBA, связанные с Backup и Recovery.

• Свести количество отказов БД к минимуму, максимизируя доступность базы данных.
• Довести до минимального значения время восстановления БД, более эффективно выполняя восстановление.
• Обеспечить минимальные потери информации, а по возможности вообще обойтись без них.

Небольшое послесловие к "роли DBA в истории".

30 марта 2001 г. в Oracle Magazine RE была опубликована статья А. Бачина - Комментарий администратора базы данных к статье "Действительно ли необходим администратор базы данных?" Я процитирую небольшой кусочек из нее.

"И в этих условиях гигантского нарастания объемов баз данных и их общего количества Т.Канти задает и сам же отвечает на парадоксально-наивные вопросы:

• "Требуется ли Администрирование Базы Данных?" - "Да!!"
• "Нужен ли АБД?" - "Не обязательно"".

Мне кажется, что Канти написал это про нашу организацию. Только тут я столкнулся с ситуацией, когда администратор не занимается "наиболее важной частью Администрирования Базы Данных - предотвращением", а "простои, повреждения, потери данных и плохую производительность" использует в качестве инструмента давления на администрацию.

Не могу удержаться еще от одной цитаты из этой статьи (В конце концов, почему бы не повторить правильные слова).

"Из этого следует, что к прочим требованиям, предъявляемым АБД, должно добавить наличие высоких моральных качеств, честности и лояльности по отношению к своей организации. Так что любой человек на должность АБД, пожалуй, не подойдет".

Благодарности.

Я хотел бы поблагодарить многих людей за помощь, оказанную во время работы над статьей. Ободряющее письмо Эдуарда Шевцова не дало оказаться черновикам статьи в мусорной корзине. Чтение сообщений из fido7.ru.rdbms.oracle и relcom.comp.dbms.oracle периодически подтверждало актуальность некоторых поднятых здесь тем.

Особое спасибо хочется сказать Стиву Адамсу за материалы из его рассылки. Кроме неоценимой помощи в повседневной работе, они помогают в борьбе с "моим несносным английским".

Еще хотелось бы поблагодарить Михаила Яновского и Виктора Савушкина за их помощь в редактировании статьи, а также мою маму, исправившую кучу ошибок в исходном тексте. Владимир Бегун и товарищи из fido7 нашли несколько неточностей в предварительном варианте

Ах, да, я совсем забыл про авторов описанных решений и приведенного тут кода. Если бы не вы, нам не о чем бы было поговорить сегодня.

Литература.

• [1] Десять главных рекомендаций по настройке приложений. Адам Джефферсон, Главный консультант корпорации Oracle UK. 29 апреля 2000 г. Oracle Magazine RE.
• [2] Мнение Эллисона: выбрасывайте все это и начинайте снова. 29 апреля 2000 г. Oracle Magazine
• [3] Oracle8. Forms Developer. Form Builder Reference, Volume 2. Release 6i. January, 2000. Part No: A73074-01.
• [3] Network Performance with the Oracle RDBMS. Roberto Zamora and Cameron Melvin. Oracle Corporation. IOUG-A Live! 98
• [4]Джемини Беллмюлле. Настройка SQL*Net с учетом особенностей основных сетевых протоколов. Русское издание Oracle Magazine №3(5) 1997г.
• [5] Oracle8i Application Developer's Guide - Fundamentals. Release 2 (8.1.6). Part Number A76939-01.
• [6] Peter Koletzke. An "Object-Oriented" Approach to Oracle Developer Forms and Reports 6.0. IOUG-A Live! 2000.
• [7] I/O Tuning with Different RAID Configurations. Note:30286.1.
• [8] Gaja Krishna Vaidyanatha, Quest Software Inc. Implementing Raid On Oracle Systems. Русскоязычный перевод доступен на http://www.oradba.com.ru
• [9] Juan Loaiza, Oracle Corporation. Optimal storage configuration made easy.
• [10] Configuring the Oracle Database with VERITAS Software and EMC Storage for Optimal Scallability, Mangeability, And Performance.
• [11] Steven Feuerstein, Bill Pribyl. Oracle PL/SQL Programming. Second Edition.
• [12] Adaptive Tablespace Management. Alex Tsukerman & Bhaskar Himatsingka, Oracle Corporation. IOUG-A Paper #712
• [13] Пейдж Вильям Дж. и др. Использование Oracle8/8i. Специальное издание.: Пер. с англ. - М.: Издательский дом "Вильямс", 2000.
• [14] Outage Prevention, Detection, And Repair. Lawrence To. Center of Expertise Worldwide Customer Support Oracle Corporation. October 1995.
• [15] List of Database Outages. Lawrence To. Center of Expertise e-Business Support Services Oracle Corporation. October 1999.

Часть 1 - Часть 2 - Часть 3