Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Импорт в Data Pump




Экспорт в Data Pump

Новая утилита известна под названием expdp, чтобы отличить ее от exp - изначального экспорта. Data Pump производит файловые манипуляции на стороне сервера, чтобы создать и прочитать файлы; таким образом, директории используются локально. Поэтому мы используем файловую систему /u02/dpdata1 для управления dump-файлами.

create directory dpdata1 as '/u02/dpdata1';

grant read, write on directory dpdata1 to ananda;

Далее мы экспортируем данные:

Expdp ananda/abc123 tables=CASES directory=DPDATA1

dumpfile=expCASES.dmp job_name=CASES_EXPORT

Импорт в Data Pump

Импорт данных, производимый Data Pump, действительно, производит впечатление. Для импортирования ранее экспортированных данных используем:

impdp ananda/abc123 directory=dpdata1 dumpfile=expCASES.dmp job_name=cases_import

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

 

Восстановление случайно утраченных таблиц - это несложное использование опции Flashback Table в Oracle Database 10g.

Далее сценарий, который происходит чаще, чем должен: пользователь, конечно же, случайно удаляет очень важную таблицу, и требуется как можно скорее ее восстановить. (В некоторых случаях этим пользователем-неудачником можете оказаться и вы – АБД!)

Oracle9i Database представил концепцию опции Flashback Query для возврата данных “из прошлого”, но это не может вернуть такие DDL-операции, как удаление (dropping) таблиц. В различных базах данных может помочь только обращение к механизму восстановления по времени (point-in-time) табличного пространства, а затем создание заново таблицы в текущей базе данных, используя экспорт/импорт или какой-то другой метод. Эта процедура требует значительных усилий АБД, также как и драгоценного его времени, не говоря об использовании различных базах данных для клонирования.

Примените функцию Flashback Table в Oracle Database 10g, которая делает восстановление утраченной таблицы таким же легким делом, как и выполнение нескольких операторов.

Таблица и ее компоненты помешаются в логический контейнер, известный как “recycle bin”, который аналогичен “корзине” на вашем ПК. Однако объекты не перемещаются из табличного пространства, где они были ранее, они до поры до времени занимают место там же. “Recycle bin” - это логическая структура, которая заносит в каталог все удаленные объекты. Используйте следующую команду в среде SQL*Plus, чтобы увидеть содержимое этой логическая структура, необходимо выполнить следующую команду:



 

SQL> show recyclebin

 

Все, что от вас требуется для восстановления таблицы, это использовать команду Flashback Table:

 

SQL> FLASHBACK TABLE RECYCLETEST TO BEFORE DROP;

 

FLASHBACK COMPLETE.

 

Чтобы освободить пространство, вы должны очистить recycle bin, используя:

 

PURGE RECYCLEBIN;

 

Но что надо сделать, если вы хотите удалить таблицу окончательно, без возможности применения функции отката? В таком случае вы можете ее удалить, используя:

 

DROP TABLE RECYCLETEST PURGE;

 

Эта команда не будет переименовывать таблицу в имя recycle bin, она будут окончательно удалена, как было в версиях Oracle до 10g.

Функция un-drop возвращает таблице ее оригинальное имя, но не ассоциированным объектам - индексам и триггерам, которые остаются под своими “корзинными” именами. Такие объекты, как представления и процедуры, определяемые на таблице, не перекомпилируются и остаются в инвалидном статусе. Нужно вручную отыскать их старые имена должны быть переделаны и затем применить к восстановленной (flashed-back) таблице.

 

Автоматизированный репозиторий рабочей нагрузки (Automatic Workload Repository)

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



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

До последнего времени встроенный инструментарий Statspack был решением Oracle в этой области. Но, являясь неоценимым набором возможностей во многих случаях, этот механизм не обладает достаточной устойчивостью, требуемой при рассмотрении проблем производительности. База данных Oracle Database 10g предлагает существенное усовершенствование: а именно, AWR (Automatic Workload Repository – автоматизированный репозиторий рабочей нагрузки). AWR инсталлируется вместе с базой данных и собирает не только статистику, но также и выводимые показатели (metrics - метрики).

В целом AWR представляет собой встроенный в Oracle инструмент, который собирает статистические данные, связанные с выполняемыми работами, и выводит из них метрики производительности, чтобы обнаружить потенциальные проблемы. В отличие от Statspack, AWR-снимки собираются автоматически каждый час новым фоновым процессом по имени MMON и его подчиненными процессами. Для экономии пространства собранные данные автоматически удаляются через 7 дней. И частота получения снимков, и период их сохранения (retention) могут изменяться пользователем. Для того, чтобы увидеть существующие параметры настройки, можно использовать запрос:

 

select snap_interval, retention

from dba_hist_wr_control;

 

SNAP_INTERVAL RETENTION

------------------- -------------------

+00000 01:00:00.0 +00007 00:00:00.0

 

Этот SQL-запрос показывает, что снимки создаются каждый час, а их коллекции (collection – совокупность) сохраняются семь дней. Для того чтобы изменить параметры настройки, скажем, интервал получения снимка на 20 минут и период сохранения до двух дней, нужно выполнить следующее. Параметры определяются в минутах.

 

begin

dbms_workload_repository.modify_snapshot_settings (

interval => 20,

retention => 2*24*60

);

end;

 


mylektsii.ru - Мои Лекции - 2015-2019 год. (0.006 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал