Базы данных Oracle - статьи
приоритеты изменяются. Предприятия реорганизуются, приобретают
С течением времени бизнес- приоритеты изменяются. Предприятия реорганизуются, приобретают другие предприятия, “наращивают мускулы” некоторых приложений и сокращают использование других. При всех этих изменениях компании сталкиваются с проблемой эффективного и экономного предоставления своих ресурсов для приведения их в соответствие с бизнес-приоритетами. Чтобы получить данные там, где вы этого хотите, и когда вы испытываете в них необходимость, требуются сложные технологии интеграции информации.
Oracle Database 10g предлагает устойчивые и полные решения для разрешения всех ваших требований к интеграции информации. Эти решения обеспечивают доступ к информации тогда и в том месте, где в ней возникает необходимость, оптимизируя доступ к этой информации независимо от ее физического местоположения. Они интегрируют информацию во всей распределенной среде, будь то в пределах grid, или для нескольких автономных систем, или для некоторой их комбинации.
Эта статья затрагивает вопросы интеграции информации с использованием распределенного SQL, Oracle Streams, Oracle Transparent Gateways и других возможностей переноса данных. Oracle Streams предлагает единую унифицированную среду для совместного использования данных, включая организацию очереди обмена сообщениями и репликацию. Oracle Transparent Gateways делает возможным прозрачный доступ из среды Oracle к системам других производителей. InfiniBand – решение для высокоскоростного внутреннего соединения – предлагает сетевую технологию нового поколения для обеспечения соединений. Далее в этой статье описывается, как эти характеристики делают возможным не только эффективную интеграцию информации и возможность взаимодействия, но и эффективное предоставление данных для grid-вычислений.
Трудно поверить, что РСУБД Oracle существует свыше 22 лет: Поразительно, но это истинный факт. За этот период она претерпела существенные изменения. Прошедшие годы (когда осуществлялась трансформация существенной части функциональных возможностей) превратили ее в безапелляционную, вынуждающую нас следить за изменениями, систему. Каждый выпуск новой основной версии Oracle заставлял некоторых из нас чувствовать, что мы должны вновь изучать все концепции. Лично я с появлением каждой основной версии Oracle чувствовал себя совершенно новым АБД. [Прим.А.Бачина: я же, наоборот, видя, что основные архтитектурные концепции сохраняются и развиваются, достаточно уверенно переходил с одной версии Oracle на следующую.]
В мире, который требует от нас сопровождения хорошо спроектированных и имеющих хорошую производительность коммерческих приложений, работающих 24x7x"вечность", существует насущная необходимость - не отставать от времени. Неспособность делать это заканчивается для нас распространением старых и потенциально неприменимых технических решений. Все мифы и фольклор, рассматриваемые в этой статье, связаны с вопросами производительности. Хотя рассмотренный список не является всеобъемлющим, он охватывает некоторые общие вопросы, находящиеся в пределах контекста оптимизации производительности Oracle. Так что вы возьмете из легенды о Лох-Нессе? Действительно ли Несси (так ее нежно называют) существует?
Потеря таблицы целиком, или нужных строк из нее, есть классический несчастный случай при работе с базой данных и практика БД не может не давать на него ответ. И в общей практике баз данных, и в Oracle в частности есть многообразие способов выкрутиться из возникшей неприятности, а конкретные действия зависят от суммы обстоятельств.
Одни способы позволяют (в некоторых случаях) восстановить образ требуемой таблицы на известный момент в прошлом. Другие позволяют (в некоторых случаях) отследить историю изменений таблицы и отменить выявленные, впоследствие нежелательные, удаления. Конкретные решения могут диктоваться следующими техническими факторами:
а) версией СУБД
б) наличием или отсутствием физической копии
в) наличием или отсутствием у используемой БД режима архивирования освободившихся журналов.
Заметим также, что в нашем случае речь идет о восстановлении данных от логических потерь, а не физических (разрушений файлов), что может потребовать давней, а не самой последней по времени физической резервной копии. Кроме того восстанавливать (вообще-то) можно как непосредственно образ таблицы, то есть сразу ее состояние на положенный момент времени, так и историю изменений , по которой затем реконструировать потерянные данные самостоятельно. Вот некоторые варианты восстановления:
? для всех версий Oracle можно восстановить образ таблицы, снятый ранее программой exp
? для всех версий можно восстановить образ таблицы по имеющейся холодной копии БД на момент снятия этой копии
? для всех версий можно восстановить образ таблицы по имеющейся горячей копии БД (работающей в режиме архивирования) на любой момент со времени снятия этой копии
? с версии 9 можно восстановить образ таблицы по состоянию недавнего прошлого, если за это время к таблице не применялись операции DDL [по информации из сегментов отката]
? с версии 10 можно восстановить образ таблицы по состоянию недавнего прошлого независимо от применения к ней операций DDL [по мусорной корзине в табличном пространстве]
