Организация и методы резервирования данных в СУБД Oracle

· background_dump_dest

· core_dump_dest

· user_dump_dest

· audit_file_dest

· log_archive_dest_<n>

· log_archive_dest\log_archive_duplex_dest

· db_recovery_file_dest

Предоставить права на эти каталоги пользователю, под учетной записью которого работает Оракл.

Далее следует разместить сохраненные файлы следующим образом: файлы данных, управляющие и журнальные файлы раскладываются по их изначальному местоположению на исходной машине. Файл параметров при необходимости переименовываем в init<SID>.ora и помещаем в директорию <$oracle_home>\database (<$oracle_home>/dbs).

Следующая последовательность действий зависит от используемой операционной системы

Windows

1. устанавливаем переменную окружения oracle_sid

set oracle_sid=<SID>

где <SID> =< instance_name >

2. создаем службу

<$oracle_home>\bin\oradim.exe -new -sid <SID> -intpwd <пароль пользователя sys\internal> -startmode manual

в результате в сервисах появится и стартует служба с именем OracleService<SID>, а в директории

<$oracle_home>/database сформируется файл паролей с именем pwd<SID>.ora

Unix

1. устанавливаем переменную ORACLE_SID

ORACLE_SID=<SID>

export ORACLE_SID

2.создаем файл паролей

<$oracle_home>/bin/orapwd file=<$oracle_home>/dbs/orapw<SID> password=<пароль пользователя sys\internal>

На этом этапе система готова к открытию базы данных.

Дальнейшие действия отличаются для разных версий Oracle.

Для версии 8 открытие базы осуществляется из командной строки программы <$oracle_home>\bin\svrmgrl

SVRMGRL> connect internal

password: <пароль пользователя internal>

connected.

SVRMGRL>startup

ORACLE instance started.

…

Database mounted.

Database opened.

Для 9-10 версии используется SQLPLUS- <$oracle_home>\bin\sqlplus

Enter user-name: sys as sysdba

Enter password: <пароль пользователя sys>

connected.

SQL> startup pfile='<$oracle_home>/dbs/init<SID>.ora';

ORACLE instance started.

…

Database mounted.

Database opened.

После открытия базы данных при наличии временных пространств, использующих tempfiles необходимо их создать командой

SQL>alter tablespace <ТП> add tempfile <путь и имя файла> size 500M

Последний этап - обеспечить пользовательский доступ к базе данных средствами Net8. Корректируются файлы tnsnames.ora и listener.ora из сохраненной директории <$oracle_home>/network/admin - в них необходимо изменить параметр host и после этого стартовать процесс прослушиватель : <$Oracle_home>\bin\lsnrctl

LSNRCTL>start

4.2.2 В измененной структуре каталогов

· Изменение каталога для файлов трассировки процессов и расположения архивных журналов осуществляется путем корректировки параметров файла init<SID>.ora

background_dump_dest

core_dump_dest

user_dump_dest

audit_file_dest

log_archive_dest_<n>

log_archive_dest\log_archive_duplex_dest

db_recovery_file_dest

· Изменение каталога расположения управляющих файлов осуществляется путем корректировки параметра файла init<SID>.ora control_files

· Изменение местоположения файлов данных и журнальных файлов осуществляется следующим образов:

-- база данных монтируется, но не открывается

SQL>startup mount ;

-- файлы данных и журнальные файлы средствами ОП раскладываются

-- по новому местоположению и для каждого из них выполняется команда

SQL>alter database rename file <путь и имя файла> to <новый путь и имя файла>;

-- например: alter database rename file `d:\dbs\redo01.log` to `c:\oracle\redo01.log`;

-- база открывается для общего доступа

SQL>alter database open;

4.2.3 Восстановление при отсутствии части необходимых файлов

Восстановление базы данных может быть проведено и в случае отсутствия части файлов, перечисленных в пункте I. Частичное восстановление возможно при утере части файлов данных, не принадлежащих табличному пространству system

· Отсутствует файл параметров инициализации. Минимальный набор параметров для старта базы данных

control_files

db_name

db_block_size

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

Значение остальных параметров берутся по умолчанию и в дальнейшем при необходимости могут быть скорректированы. Если значения параметров db_name и db_block_size не известны, можно поставить произвольные значения - при попытке старта Оракл обнаружит несоответствия этих параметров с указанными в управляющем файле и выдаст ошибку (на консоль или в alert.log) с указанием их истинных значений.

· Отсутствуют журнальные файлы.

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

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

SQL>startup mount;

…

SQL> recover database until cancel using backup controlfile;

ORA-00279: change 4657702 generated at 11/26/2005 17:04:52 needed for thread 1

ORA-00289: suggestion : D:\ORA9\RDBMS\ARC00008.001

ORA-00280: change 4657702 for thread 1 is in sequence #8

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Cancel -- на предложение ввести команду

Media recovery cancelled.

SQL> alter database open resetlogs;

Database altered.

· Отсутствуют управляющие файлы.

В случае мультиплексирования журнальных файлов отсутствующий файл можно заменить любым из сохранившихся или удалить упоминания о нем из параметра инициализации control_files. Если же не сохранилась ни одна из текущих копий файла, можно использовать: backup-копию + последовательность команд из предыдущего пункта, ведущая к открытию в режиме resetlogs, либо применить скриптовое создание управляющего файла на основе скрипта, сгенерированного командой alter database backup controlfile to trace на исходной базе.

Общая структура SQL-конструкции для создания управляющего файла:

CREATE CONTROLFILE SET DATABASE TEST RESETLOGS NOARCHIVELOG

MAXLOGFILES 50

MAXLOGMEMBERS 5

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 'Q:\REDO01.LOG' SIZE 100M,

GROUP 2 'Q:\REDO02.LOG' SIZE 100M,

GROUP 3 'Q:\REDO03.LOG' SIZE 100M

DATAFILE

'Q:\SYSTEM01.DBF',

'Q:\UNDO1.DBF'

CHARACTER SET CL8MSWIN1251;

Создание управляющего файла осуществляется в режиме nomount. В случае использования сгенерированного скрипта следует:

- поменять параметр reuse на set в первой строке CREATE CONTROLFILE REUSE DATABASE

- установить параметр resetlogs\noresetlogs в зависимости от того, присутствуют ли в резервной копии журнальные файлы и требуется ли сохранить последовательность их нумерации

- тут же можно изменить местоположение файлов и удалить упоминания об отсутствующих файлах данных

В результате выполнения сценария CREATE CONTROLFILE заново создадутся управляющие файлы базы данных и сама база перейдет в состояние mount.

Далее, база данных открывается фразой

SQL>alter database open ;

или

SQL>alter database open resetlogs;

Пересоздание управляющего файла можно использовать для изменения пути к файлам данных и журнальным файлам. В этом случае соответствующие строки корректируются таким образом, чтобы они отражали новые пути и переименование файлов командами SQL в дальнейшем не требуется. Так же может быть изменен размер журнальных файлов и исключены потерянные файлы данных (в этом случае обязательно использование resetlogs).

· Отсутствует часть файлов данных, не принадлежащих табличному пространству system (sysaux)

Отсутствующие файлы данных могут быть удалены из базы с потерей всех содержащихся данных выполнением следующей команды

SQL>startup mount;

…

SQL>alter database datafile 'путь и имя файла' offline drop;

SQL> alter database оpen;

4.3 Восстановление базы данных на локальной машине

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

· Для клонированной базы данных создаем структуру каталогов для размещения файлов базы и файлов трассировки, предоставляем необходимый права пользователю и изменяем файл параметров инициализации. Кроме перечисленных в пункте II.3 параметров, должны быть установлены\переопределены параметры

SERVICE_NAME=<NEW_SID>

INSTANCE_NAME=<NEW_SID>

LOCK_NAME_SPACE =<NEW_SID>

Windows.

1. устанавливаем переменную окружения oracle_sid

set oracle_sid=<NEW_SID>

2. создаем службу

<$oracle_home>\bin\oradim.exe -new -sid <NEW_SID> -intpwd <пароль sys\internal> - startmode manual

в результате в сервисах появится и стартует служба с именем OracleService<NEW_SID>, а в директории <$oracle_home>/database сформируется файл паролей с именем pwd<NEW_SID>.ora

Unix.

1. устанавливаем переменную ORACLE_SID

ORACLE_SID=<NEW_SID>

export ORACLE_SID

2.создаем файл паролей

<$oracle_home>/bin/orapwd file=<$oracle_home>/dbs/orapw<NEW_SID> password=<пароль пользователя

sys\internal>

· Стартуем базу данных в режиме mount и осуществляем переименование файлов.

· При необходимости создаем темп-файлы и открываем базу.

· Добавляем в tnsnames.ora псевдоним для созданной базы. В случае необходимости корректируем файл listener.ora и перезапускаем процесс прослушивания: <$Oracle_home>\bin\lsnrctl

LSNRCTL>stop

LSNRCTL>start

4.4 Создание резервной копии методом «горячего» копирования

Метод холодного копирования не применим для баз данных, требующие непрерывного постоянного доступа пользователей, поскольку данный метод предполагает закрытие БД.

Если производственные потребности не позволяют прервать работу базы данных, то используется механизм выполнения резервирования базы данных в ходе ее использования - горячее резервное копирование (online backup). Метод «горячего» резервного копирования применяется только для баз данных, функционирующих в режиме archivelog. Копировать БД рекомендуется в период ее наименьшей нагрузки.

Перед началом резервирования следует определить табличные пространства базы данных и соответствующие им файлы.

SQL>select v$tablespace.name, v$datafile.name from v$tablespace, v$datafile

where v$tablespace.ts#=v$datafile.TS#;

Определенные таким образом табличные пространства на момент осуществления физического копирования их файлов данных должны быть переведены в режим «backup» командой

SQL> alter tablespace <tablespace> begin backup;

После завершения копирования необходимо выполнить оператор

SQL> alter tablespace <tablespace> end backup;

При этом переводить табличный пространства в backup-режим можно как последовательно, так и одновременно.

Резервирование табличных пространств, находящихся в режиме offline и read only осуществляется без перевода их в режим «backup». Статус табличного пространства можно определить из представления dba_tablespaces.

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

SQL> alter database backup controlfile to <tarce\file_name>

и

SQL> alter system archive log current;

Для восстановления базы данных будут затребованы все архивные журнальные файлы, сформированные с момента перевода первого табличного пространства в режим «backup».

4.5 Восстановление базы данных из «горячей» копии

Процесс восстановления базы данных из «горячей» копии отличается тем, что перед открытием базы необходимо осуществить восстановление носителя c использованием резервной копии управляющего файла. Перед этим рекомендуется поместить необходимые архивные журнальные файлы в директорию log_archive_dest \log_archive_dest_1\db_recovery_file_dest

SQL> startup mount;

SQL> recover database until cancel using backup controlfile;

На запрос имени архивного журнала ввести AUTO либо полный путь к файлу. После того, как все журнальные файлы применятся, открыть базу данных с опцией resetlogs

SQL> alter database open resetlogs;

Глава 5. Резервирование и восстановление

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

У любого бизнеса должна быть стратегия восстановления после катастроф, которые приводят к потере данных. В настоящее время только 45% компаний из списка крупнейших компаний мира имеют формальные стратегии для своей защиты от бедственной потери данных. Только 12% из этих стратегий рассматриваются на корпоративном уровне ("Calculating the Cost of Downtime" (вычисление стоимости времени простоя)). При разработке формальной стратегии АБД должны планировать потерю данных из-за неожиданных отказов, причинами которых могут быть аппаратные или программные сбои, человеческие ошибки, природные явления и т.д. Для каждого из таких возможных событий АБД должны иметь план действий. В некоторых случаях может потребоваться восстановление носителя, в других будет достаточно восстановления экземпляра. Для обеих этих ситуаций АБД должны иметь планы действий. Мы рассмотрим их в этом разделе ниже. В конце концов, администратор базы данных и системный администратор должны документировать среду базы данных и стратегии восстановления, чтобы при возникновении сбоя АБД мог диагностировать проблему и немедленно заняться ее решением.

5.1 Планирование восстановления экземпляра

Работа систем может аварийно завершаться по разным причинам, например, из-за прекращения подачи электроэнергии. В этом случае после перезапуска экземпляра СУБД и до открытия базы данных для пользователей будет выполняться восстановление экземпляра. Цель восстановления экземпляра - восстановление физического содержимого базы данных в транзакционно согласованное состояние. Поэтому во время восстановления должны применяться все сделанные зафиксированными транзакциями изменения, которые находились в кеше буферов и не были записаны на диск до сбоя, а затем выполняется откат всех записанных на диск изменений, сделанных незафиксированными транзакциями. Восстановление экземпляра выполняется внутренними механизмами СУБД Oracle и не требует вмешательства администратора. Единственный аспект, о котором должен заботиться АБД - продолжительность выполнения восстановления; это легко контролируется настройкой в файле инициализации параметра FAST_START_MTTR_TARGET (MTTR - mean time to recover, среднее время восстановления). В системах, в которых размер кеша буферов составляет много гигабайтов, восстановление экземпляра может быть очень длительным с совершенно не предсказуемым временем восстановления. Для АБД оба эти свойства мало допустимы. Новая опция быстрого восстановления с предсказуемым временем (Fast-Start Time-Based Recovery) в СУБД Oracle9i позволяет АБД задавать среднее время восстановления экземпляра (в секундах) с помощью установки значения в параметре FAST_START_MTTR_TARGET. Эта опция реализуется ограничением количества "грязных" буферов и количества журнальных записей, сгенерированных после последней контрольной точки. Для обеспечения заданного времени восстановления сервер базы данных по существу регулирует скорость выполнения контрольных точек.

Если в параметре FAST_START_MTTR_TARGET установлено слишком низкое значение, сервер базы данных будет писать на диск очень часто, и это может привести к снижению скорости работы системы. Поэтому этот параметр необходимо настраивать так, чтобы сервер не выполнял чрезмерное количество контрольных точек, но при этом время восстановления оставалось бы в приемлемых пределах. С этой целью в СУБД Oracle9i Release 2 введена новая консультативная справка по MTTR (MTTR Advisory). Эта справка позволяет экземпляру оценивать (в процентах) изменение количества записей на диск, которое могло бы произойти при других значениях в параметре FAST_START_MTTR_TARGET. Используя оценку, полученную при типичной рабочей нагрузке на экземпляр, вы можете определить влияние повышения или понижения значения в данном параметре. Значения консультативной справки по MTTR содержатся в представлении V$MTTR_TARGET_ADVICE. Это представление имеет пять строк, которые показывают предполагаемую дисковую активность при различных значениях в параметре FAST_START_MTTR_TARGET: текущее значение; приблизительно десятая часть текущего значения; приблизительно половина текущего значения; приблизительно полтора текущего значения и приблизительно двойное текущее значение. В Enterprise Manager можно получить графическое представление консультативной справки по MTTR (см. рис. 6).

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

Рис. 6. Консультативная справка по MTTR.

5.2 Планирование восстановления носителя

5.2.1 Стратегия резервирования

Восстановление носителя требуется всегда, когда теряются данные. Наиболее общие причины потери данных: сбои носителя и человеческие ошибки. Для того чтобы можно было восстанавливать носитель, сервер базы данных должен функционировать в режиме ARCHIVELOG (архивирование журнала). Его легко включить с помощью оператора ALTER DATABASE. Затем АБД должны выбрать метод резервирования. В прошлом АБД писали свои собственные скрипты для резервирования базы данных. Сейчас делать это уже нецелесообразно, так как утилита Recovery Manager (диспетчер восстановления) лучше оснащена для управления резервированием. Утилита Recovery Manager имеет вариант с интерфейсом командной стоки, а также вариант с графическим интерфейсом, встроенным в Enterprise Manager. Утилита Recovery Manager позволяет пользователям специфицировать все их требования резервирования, например, полное оперативное резервирование базы данных на ленту, автономное резервирование всей базы данных на диск и т.п. Более того, использование средств планирования в Enterprise Manager позволяет запускать задания создания резервных копий в заданное время, как регулярно, так и по потребности. Хорошая практическая рекомендация: вместе с резервными копиями файлов данных базы данных создавать резервную копию управляющего файла. Резервную копию управляющего файла, как минимум, необходимо создавать при изменении структуры базы данных.

Для тех администраторов, которым требуются также файлы систем резервирования, корпорация Oracle инициировала, совместно с поставщиками систем управления носителями, программу решения проблем резервирования (Backup Solution Program,http://otn.oracle.com/deploy/availability). Участники этой программы - сторонние поставщики, инструментальные средства которых обеспечивают комплексное решение вопросов резервирования как системных файлов, так и файлов базы данных Oracle. Это лучше использования для управления резервированием двух отдельных инструментов, Recovery Manager или Enterprise Manager для файлов базы данных Oracle и отдельного инструмента для системных файлов.

Как обсуждалось ранее, журнальные файлы следует мультиплексировать. Это означает, что каждая журнальная группа будет иметь два журнальных файла или элемента. Настоятельно рекомендуется, чтобы задание создания резервных копий резервировало по крайней мере два элемента каждой журнальной группы. Это подчеркивает важность журнальных файлов, поскольку если во время восстановления возникнут проблемы с архивными журнальными файлами из-за их физического повреждения или человеческой ошибки, то полное восстановление базы данных будет невозможным, и это приведет к потере некоторых данных. Вероятность такого происшествия существенно уменьшается, если есть запасная резервная копия. Заметим, АБД не должны создавать резервную копию журнального файла, а затем резервировать ее еще один раз. Вместо этого они должны резервировать два зеркальных журнальных файла по отдельности, так чтобы в случае повреждения одного из них для восстановления был доступен второй журнальный файл. Если обе копии являются копиями одного и того же архивного журнального файла, то мы не защищаем себя от повреждений журнала.

5.2.2 Стратегия восстановления

АБД должны моделировать сценарии потери данных и тестировать свои планы восстановления. К сожалению, большинство АБД не тестируют свои стратегии резервирования и восстановления. Проведение испытаний плана восстановления помогает проверить процессы на месте, а также держит администраторов в курсе проблем и ловушек восстановления. Четыре основные причины потери данных: сбои носителя, человеческие ошибки, повреждение блоков данных и стихийные бедствия. План восстановления необходимо разрабатывать с учетом каждого случая.

· Сбой носителя.

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

· Человеческая ошибка.

Пользователи могут непредумышленно удалять данные или уничтожать таблицы. Хороший способ минимизации последствий таких ситуаций - предоставлять пользователям только такие привилегии базы данных, которые им безусловно необходимы. Но человеческие ошибки будут по-прежнему возникать и АБД должны быть готовы к работе над ними. Создание логических резервных копий или экспорт таблиц - хороший способ справляться со случайными уничтожениями таблиц. Ретроспективный запрос (Flashback Query), новое средство, введенное в СУБД Oracle9i, очень хорошо подходит для восстановления после случайных удалений или вставок. Последним средством, к которому можно прибегнуть, является копирование из резервной копии и восстановление всего табличного пространства, содержащее объекты, на которые подействовала человеческая ошибка. Существуют различные методы восстановления после человеческих ошибок, и все они должны быть протестированы.

· Повреждение блоков данных.

Неисправная аппаратура или ошибка операционной системы могут быть причиной повреждения блоков данных, в результате которого их формат не будет распознаваться СУБД Oracle или их содержимое будет внутренне несогласованным. В СУБД Oracle имеется средство восстановления носителя на уровне блоков (Block Media Recovery), которое копирует и восстанавливает только поврежденные блоки, и не требует восстановления всего файла данных. Это уменьшает среднее время восстановления (MTTR, Mean Time to Recovery), так как копируются и восстанавливаются только те блоки, которые требуется восстановить, а испорченные файлы данных остаются в оперативном режиме.

· Стихийные бедствия.

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

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

Глава 6. Практическая часть

Резервное копирование предоставляет возможность восстановления информационной системы с данными после различного рода инцидентов, имеющих технический, программный или внешний характер, и приводящих к уничтожению информационной системы и/или данных (всех или части).

Для обеспечения процедуры резервного копирования данных информационной системы необходимо следующее:

1. создание специального скрипт-файла, при запуске которого будет создаваться файл-архив содержащий:

· копию рабочей схемы базы данных (объект базы данных содержащий данные пользователя);

· резервную копию программного кода базы данных из всех задействованных схем;

· копию всех шаблонов печатных форм и отчетов;

2. Включение в рабочий режим функций базы Oracle по созданию журналов всех транзакций (операций с данными) для обеспечения возможности восстановления состояния данных на любой момент времени, а не только на момент создания резервной копии (т.н. Archive Logs).

3. Настройку Планировщика Заданий Windows (или другой аналогичной программы) на автоматическое выполнение скрипт-файла, по определенному расписанию.

В процессе выполнения мною дипломной работы было выполнено следующее - установлена и настроена СУБД Oracle версии 10g. Создана точная копия тестового сервера и проверена на работоспособность (здесь включен импорт всех необходимых схем), была настроена ее архивация несколькими методами, которые дальше будут продемонстрированы.

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

1) Метод ведения архивации с помощью встроенных функций в СУБД ORACLE. Команды exp и imp (что есть «export» и «import»)

В следующем примере формируется файл, с расширением *.dmp.

Файл archive_db.bat содержит следующий скрипт:

chcp 1251

rem удаление *.log файлов

del *.log

rem логин/пароль@сервер скрипт очистки ZTEMP

sqlplusw schema_name/schemas_name@name_db @clearztemp

rem логин/пароль@сервер название схемы лог файл *.dmp файл экспорта

exp 'sys/sys@name_db as sysdba' owner=schema log=log_name.log file=file_name.dmp

rem Обязательные схем

exp 'sys/sys@name_db as sysdba' owner=un4pack log=un4pack.log file=exp_un4pack.dmp

exp 'sys/sys@name_db as sysdba' owner=un4public log=un4public.log file=exp_un4public.dmp

rem путь сохранения архивов все *.dmp файлы все лог файлы путь к templates

rar a -agddmmyy_HHMM D:\archiv_db\Back_up\schema_name_ *.dmp *.log D:\Share\templates.ora

rem удаление *.dmp файлов

del *.dmp

Дополнительно, в папку с этим файлом можно поместить ДОСовский rar (архиватор) и указать в скрипте все файлы для сжатия и помещения их в архив, для экономии места на дисках.

Импорт данных выполняется в несколько этапов.

Для этого необходимо 6 файлов, содержащих следующие скрипты:

· Скрипт на создание схемы.

create_script_user.bat

rem Создает скрипт для генерации юзера (схемы) user.sql,

rem и вклеивает в него само имя юзера (схемы).

del user.sql

echo TRUNCATE TABLE %1.tparams DROP STORAGE; >> user.sql

echo DROP USER %1 CASCADE ; >> user.sql

echo CREATE USER %1 IDENTIFIED BY "%1" >> user.sql

echo DEFAULT TABLESPACE TBSun4_TABLES >> user.sql

echo TEMPORARY TABLESPACE TBSun4_TEMP >> user.sql

echo PROFILE DEFAULT; >> user.sql

echo GRANT ALTER ANY INDEX TO %1; >> user.sql

echo GRANT CREATE ANY TABLE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT drop ANY TABLE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT EXECUTE ANY PROCEDURE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT EXECUTE ANY TYPE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT QUERY REWRITE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT UNLIMITED TABLESPACE TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT CONNECT TO %1 WITH ADMIN OPTION; >> user.sql

echo GRANT RESOURCE TO %1 WITH ADMIN OPTION; >> user.sql

echo ALTER USER %1 DEFAULT ROLE CONNECT, >> user.sql

echo RESOURCE; >> user.sql

echo GRANT SELECT ON SYS.V_$SESSION TO %1; >> user.sql

echo GRANT SELECT ON SYS.V_$TRANSACTION TO %1; >> user.sql

echo GRANT SELECT ON DBA_OBJECTS TO %1; >> user.sql

echo GRANT SELECT ON DBA_policies TO %1; >> user.sql

rem stas

echo GRANT CREATE ANY VIEW TO UN4PUBLIC; >> user.sql

echo GRANT DROP ANY VIEW TO UN4PUBLIC; >> user.sql

rem end stas

echo GRANT EXECUTE ON SYS.DBMS_ALERT TO %1; >> user.sql

echo GRANT EXECUTE ON SYS.dbms_rls TO %1; >> user.sql

echo GRANT SELECT ON SYS.V_$LOCK TO %1; >> user.sql

echo GRANT ALTER SYSTEM TO %1; >> user.sql

echo rem GRANT SELECT ANY table TO %1 ; >> user.sql

echo GRANT EXP_FULL_DATABASE TO %1 ; >> user.sql

echo GRANT IMP_FULL_DATABASE TO %1 ; >> user.sql

echo GRANT EXECUTE ON SYS.DBMS_PIPE TO %1 ; >> user.sql

echo ALTER TABLESPACE TBSun4_TABLES coalesce; >> user.sql

echo ALTER TABLESPACE TBSun4_TEMP coalesce; >> user.sql

echo ALTER TABLESPACE TBSun4_SYSTABLES coalesce; >> user.sql

echo ALTER TABLESPACE TBSun4_IND coalesce; >> user.sql

echo ALTER TABLESPACE TBSun4_cm coalesce; >> user.sql

echo ALTER TABLESPACE system coalesce; >> user.sql

rem echo ALTER TABLESPACE indx coalesce; >> user.sql

rem echo ALTER TABLESPACE rbs coalesce; >> user.sql

echo exit ; >> user.sql

· Скрипт на создание объектов схемы.

create_dat_obj.bat

rem Создает файл параметров obj1.dat,

rem (набор параметров для утилиты IMP - чтоб не задавать в коммандной строке)

rem и вклеивает в него имена новой и старой схемы.

del obj1.dat

rem echo FILE=expancfm.dmp >> obj1.dat

rem echo LOG=imp_log.txt >> obj1.dat

echo grants=y >> obj1.dat

echo TOUSER=%1 >> obj1.dat

echo FROMUSER=%2 >> obj1.dat

echo IGNORE=Y >> obj1.dat

echo FEEDBACK=1000 >> obj1.dat

echo analyze=n >> obj1.dat

echo TOID_NOVALIDATE=(%1.UN$FANEX,%1.UN$PASAPORT,%1.UN$AFX$GRUPUZINT,%1.UN$CM,%1.UN$PRICE,%1.UN$SRNRDT,%1.UN$SUMA,%1.UN$SZ$CONTRACTRES,%1.UN$SZ$CONTRBRIG,%1.UN$SZ$CONTRCAMPS,%1.UN$SZ$CONTRDIST,%1.UN$SZ$SOFERS,%1.UNT$AFX$GRUPUZINT,%1.UNT$FANEX,%1.UNT$SZ$CONTRBRIG,%1.UNT$SZ$CONTRCAMPS,%1.UNT$SZ$CONTRDIST,%1.UNT$SZ$SOFERS) >> obj1.dat

· Скрипт, содержащий настройки последовательного выполнения импорта схемы.

imp1.bat

del *.log

rem Создать скрипт для создания нового юзера (схемы) user.sql

call create_script_user.bat %2

rem Создать файл параметров obj1.dat.

call create_dat_obj.bat %2 %3

rem запустить скрипт создания нового юзера

sqlplus sys/sys@%1 as sysdba @"user.sql"

rem запустить скрипт создания типов для данной схемы

sqlplusw %2/%2@%1 @"all_objct.sql"

rem запустить утилиту экспорта IMP

rem админ/пароль@сервер журнал файл архива из которого импортировать

rem IMP system/sys@%1 log=implog.log parfile=obj1.DAT

IMP system/sys@%1 log=implog.log parfile=obj1.DAT

· Два файла user.sql и all_objct.sql, в которых содержится скрипт на создание схемы и объектов схемы.

user.sql

TRUNCATE TABLE Dina.tparams DROP STORAGE;

DROP USER Dina CASCADE ;

CREATE USER Dina IDENTIFIED BY "Dina"

DEFAULT TABLESPACE TBSun4_TABLES

TEMPORARY TABLESPACE TBSun4_TEMP

PROFILE DEFAULT;

GRANT ALTER ANY INDEX TO Dina;

GRANT CREATE ANY TABLE TO Dina WITH ADMIN OPTION;

GRANT drop ANY TABLE TO Dina WITH ADMIN OPTION;

GRANT EXECUTE ANY PROCEDURE TO Dina WITH ADMIN OPTION;

GRANT EXECUTE ANY TYPE TO Dina WITH ADMIN OPTION;

GRANT QUERY REWRITE TO Dina WITH ADMIN OPTION;

GRANT UNLIMITED TABLESPACE TO Dina WITH ADMIN OPTION;

GRANT CONNECT TO Dina WITH ADMIN OPTION;

GRANT RESOURCE TO Dina WITH ADMIN OPTION;

ALTER USER Dina DEFAULT ROLE CONNECT,

RESOURCE;

GRANT SELECT ON SYS.V_$SESSION TO Dina;

GRANT SELECT ON SYS.V_$TRANSACTION TO Dina;

GRANT SELECT ON DBA_OBJECTS TO Dina;

GRANT SELECT ON DBA_policies TO Dina;

GRANT CREATE ANY VIEW TO UN4PUBLIC;

GRANT DROP ANY VIEW TO UN4PUBLIC;

GRANT EXECUTE ON SYS.DBMS_ALERT TO Dina;

GRANT EXECUTE ON SYS.dbms_rls TO Dina;

GRANT SELECT ON SYS.V_$LOCK TO Dina;

GRANT ALTER SYSTEM TO Dina;

rem GRANT SELECT ANY table TO Dina ;

GRANT EXP_FULL_DATABASE TO Dina ;

GRANT IMP_FULL_DATABASE TO Dina ;

GRANT EXECUTE ON SYS.DBMS_PIPE TO Dina ;

ALTER TABLESPACE TBSun4_TABLES coalesce;

ALTER TABLESPACE TBSun4_TEMP coalesce;

ALTER TABLESPACE TBSun4_SYSTABLES coalesce;

ALTER TABLESPACE TBSun4_IND coalesce;

ALTER TABLESPACE TBSun4_cm coalesce;

ALTER TABLESPACE system coalesce;

exit ;

Скрипт all_objct.sql:

CREATE OR REPLACE TYPE "UN$AFX$GRUPUZINT" AS OBJECT

( GR3 NUMBER (10) ,

PROCENT NUMBER (1,3)

);

/

CREATE OR REPLACE TYPE "UN$SUMA" AS OBJECT

(

DEF NUMBER(15,2),

GAAP NUMBER(15,2),

val NUMBER(15,2),

valuta VARCHAR2(3)

);

/

CREATE OR REPLACE TYPE "UN$CM" AS OBJECT (

ctype CHAR(1) ,

cont NUMBER(4),

cont1 NUMBER(4),

sc NUMBER(10),

dep NUMBER(10),

sc1 NUMBER(10),

nrdoc NUMBER(15),

STRSC VARCHAR2(15),

NRCM NUMBER(4),

cant NUMBER,

suma UN$SUMA

);

/

CREATE OR REPLACE TYPE "UN$FANEX" AS OBJECT (

nrord NUMBER(2),

SERIA VARCHAR2(10),

NR VARCHAR2(50),

DATA DATE

);

/

CREATE TYPE UN$PASAPORT AS OBJECT (

FAMILIA VARCHAR2 (30),

NUMELE VARCHAR2 (30),

PRENUMELE VARCHAR2 (30),

ANUL_NASTERII DATE,

PASAPORTNRSERIA VARCHAR2 (25),

ORGELOBERAT VARCHAR2 (25),

DATAELIBPAS DATE,

DOMICILIU VARCHAR2 (100)

);

/

CREATE OR REPLACE TYPE "UN$PRICE" AS OBJECT

( ID NUMBER(10),

GRP NUMBER(3),

DISC NUMBER(3,3)

);

/

CREATE OR REPLACE TYPE "UN$SRNRDT" AS OBJECT

( SERIA VARCHAR2(10),

NR VARCHAR2(50),

DATA DATE

);

/

CREATE OR REPLACE TYPE "UN$SZ$CONTRACTRES" AS OBJECT

( db DATE,

dnd DATE,

um VARCHAR2(7),

cant NUMBER(15,4)

);

/

CREATE OR REPLACE TYPE "UN$SZ$CONTRBRIG" AS OBJECT

( brigid VARCHAR2(10),

distanta NUMBER (15,4)

);

/

CREATE OR REPLACE TYPE "UN$SZ$CONTRCAMPS" AS OBJECT

( ID VARCHAR2(10), -- cod campului

distanta NUMBER (15,4), -- distanta

denumirea VARCHAR2(20), -- denumirea camp

prm1_ha NUMBER (15,2), -- Suprafata contractata, ha

prm2_ha NUMBER (15,2), -- Suprafata reala, ha

prm3_ha NUMBER (15,2), -- Suprafata sfeclei de zahar contractata, ha

prm4_ha NUMBER (15,2), -- Suprafata sfeclei de zahar reala, ha

cp01 UN$SZ$contrActRes, cp02 UN$SZ$contrActRes, cp03 UN$SZ$contrActRes, cp04 UN$SZ$contrActRes, cp05 UN$SZ$contrActRes, cp06 UN$SZ$contrActRes, cp07 UN$SZ$contrActRes, cp08 UN$SZ$contrActRes, cp09 UN$SZ$contrActRes, cp10 UN$SZ$contrActRes,

cp11 UN$SZ$contrActRes, cp12 UN$SZ$contrActRes, cp13 UN$SZ$contrActRes, cp14 UN$SZ$contrActRes, cp15 UN$SZ$contrActRes, cp16 UN$SZ$contrActRes, cp17 UN$SZ$contrActRes, cp18 UN$SZ$contrActRes, cp19 UN$SZ$contrActRes, cp20 UN$SZ$contrActRes,

cp21 UN$SZ$contrActRes, cp22 UN$SZ$contrActRes, cp23 UN$SZ$contrActRes, cp24 UN$SZ$contrActRes, cp25 UN$SZ$contrActRes

);

/

CREATE OR REPLACE TYPE "UN$SZ$CONTRDIST"

AS OBJECT

( diststart NUMBER(10,2),

distend NUMBER(10,2),

pret NUMBER (15,4)

);

/

CREATE OR REPLACE TYPE "UN$SZ$SOFERS"

AS OBJECT

( Numele VARCHAR2(20),

permisNr VARCHAR2(20),

pasaport UN$PASAPORT

);

/

CREATE OR REPLACE TYPE "UNT$AFX$GRUPUZINT" AS TABLE OF UN$AFX$GRUPUZINT ;

/

CREATE OR REPLACE TYPE "UNT$FANEX" AS TABLE OF UN$FANEX ;

/

CREATE OR REPLACE TYPE "UNT$SZ$CONTRBRIG" AS TABLE OF UN$SZ$contrbrig ;

/

CREATE OR REPLACE TYPE "UNT$SZ$CONTRCAMPS" AS TABLE OF UN$SZ$contrCamps ;

/

CREATE OR REPLACE TYPE "UNT$SZ$CONTRDIST" AS TABLE OF UN$SZ$contrdist ;

/

CREATE OR REPLACE TYPE "UNT$SZ$SOFERS" AS TABLE OF UN$SZ$SOFERs ;

/

exit;

· Файл запуска импорта

run.bat

chcp 1251

rem сервер новая схема старая схема(expdat.dmp)

imp1 name_db schema schema

rem Создаются все необходимые типы - all_objct.sql.

2) Начиная с версии Oracle 10.2, появилась возможность использования директории DATA_PUMP_DIR для резервного копирования данных. Стало возможным экспортировать не только данные, но и структуру схем, ее объекты, а также возможность сделать полный архив всей базы в один общий файл. И в дальнейшем развернуть из этого файла точную копию на новом сервере БД.

Пример:

chcp 1251

set nls_lang=AMERICAN_RUSSIA.CL8MSWIN1251

rem удаление *.log файлов *.dmp файлов из data_pump

del /Q C:\oracle\product\10.2.0\admin\cricova\dpdump

rem логин/пароль@сервер скрипт очистки ZTEMP

sqlplusw name_schema/name_schema@name_db @clearztemp

rem логин/пароль@сервер название схемы лог файл *.dmp файл экспорта

expdp 'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=dmp_name.dmp LOGFILE=log_name SCHEMAS=name_schema

expdp 'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=expdat_un4pack.dmp LOGFILE=log_un4pack SCHEMAS=un4pack

expdp 'sys/sys@name_db as sysdba' DIRECTORY=DATA_PUMP_DIR DUMPFILE=expdat_un4public.dmp LOGFILE=log_un4public SCHEMAS=un4public

rem копирование *.dmp файлов откуда куда

copy C:\oracle\product\10.2.0\admin\name_db\dpdump C:\Archive_db

rem удаление *.log файлов *.dmp файлов из data_pump

del /Q C:\oracle\product\10.2.0\admin\name_db\dpdump

rem формирование архива путь сохранения архивов все *.dmp файлы все лог файлы путь к templates

rar a -agddmmyy_HHMM C:\Archive_db\Back_up\arhiv_ *.dmp *.log C:\Shares\templates.ora

rem удаление *.dmp файлов *.log файлов

del *.dmp *.log

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

ЛИТЕРАТУРА

1. Скотт Урман, “Oracle8: Программирование на языке PL/SQL”

2. Кевин Луни, Марлен Терьо “Oracle8: Настольная книга администратора”

3. http://www.citforum.ru/database/oracle/prz/prosto.shtml#7

4. Том Кайт «Oracle для профессионалов.»

5. Джонатан Генник «Oracle SQL*Plus.

6. http://www.sql-ex.ru/help/select0.php?Lang=0

7. “Oracle Database 10g: Simplify Your Job with Automatic Storage Management”https://www.oracleworld2003.com/published/40140

8. T. Bednar. Database Backup and Recovery: Strategies and Best Practices.

9. S. Kumar. Server Manageability: DBA's Mantra for a Good Night's Sleep.

10. http://citforum.ru/database/oracle/oracleadm/

Размещено на Allbest.ru