Что такое Oracle dbid

Обновлено: 21.11.2024

До введения утилиты DBNEWID изменение внутреннего DBID экземпляра было невозможно, а изменение DBNAME требовало создания нового управляющего файла. Утилита DBNEWID позволяет впервые изменить DBID и упрощает изменение DBNAME. Изменение DBID необходимо, если вы хотите использовать каталог RMAN для резервного копирования клонированного экземпляра. RMAN идентифицирует экземпляры с помощью DBID, предотвращая управление исходным и клонированным экземплярами одним и тем же каталогом. Изменение BID в клонированном экземпляре снимает это ограничение.

DBID и DBNAME

  • Создайте резервную копию базы данных.
  • Смонтируйте базу данных после полного завершения работы.
  • Вызовите утилиту DBNEWID (nid), указав новое имя DBNAME из командной строки, используя пользователя с привилегией SYSDBA.
    Если проверка прошла успешно, утилита запрашивает подтверждение перед выполнением действий. Типичный вывод может выглядеть примерно так:
  • Завершите работу базы данных.
  • Измените параметр DB_NAME в файле параметров инициализации. Запуск приведет к ошибке, но все равно продолжится.
  • Создайте новый файл паролей.
  • Переименуйте SPFILE, чтобы он соответствовал новому DBNAME.
  • Если вы используете Windows, вы должны заново создать службу, чтобы использовать правильное имя и файл параметров.
    Если вы используете UNIX/Linux, просто сбросьте переменную среды ORACLE_SID.
  • Измените настройки listener.ora и tnsnames.ora, чтобы они соответствовали новому имени базы данных, и перезапустите прослушиватель.
  • Откройте базу данных с помощью RESETLOGS.
  • Создайте резервную копию базы данных.

Только DBNAME

Повторите процесс, как и раньше, но используйте следующую команду для запуска утилиты DBNEWID.

Параметр SETNAME указывает утилите DBNEWID изменять только имя базы данных.

При открытии базы данных параметр RESETLOGS не требуется, поэтому базу данных можно запустить с помощью команды STARTUP.

DBID — очень важная часть баз данных Oracle. Это внутренний, уникально сгенерированный номер, который отличает базы данных. Oracle создает этот номер автоматически, как только вы создаете базу данных.

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

Или вы можете просто выбрать его в представлении v$database.

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

Вы можете просмотреть файл alert.log или любой другой файл трассировки в месте назначения DIAG, но вы не найдете там DBID.

Итак, если единственное, что у вас осталось, это ваш каталог RMAN и ваши копии файлов данных в ваших FRA + Archivelogs, то вам нужно заранее получить DBID, прежде чем вы сможете правильно восстановить/восстановить свою базу данных.

Есть три возможности получить DBID

  • Вы можете проверить файлы журнала резервного копирования RMAN, если вы правильно его настроили
  • Вы можете подключиться к своему каталогу RMAN и запросить таблицу «БД» у владельца каталога. Будьте осторожны, может быть более одной записи для вашего имени БД, и тогда может быть сложно получить правильную. В моем примере у меня есть только одна запись
  • И, в крайнем случае, вы можете запустить nomount (либо с резервным файлом pfile, либо с фиктивным экземпляром RMAN), а затем выгрузить заголовки ваших копий файлов данных в FRA.

Обычно достаточно выгрузить первый блок, кроме того, вы не ограничены файлом данных SYSTEM. Вы можете использовать любые копии ваших файлов данных в FRA (например, SYSAUX, USERS и т. д.) для вывода блока, как показано в следующем примере:

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

Заключение

Не забудьте где-нибудь сохранить DBID вместе с заданиями резервного копирования RMAN. Восстановление базы данных в 3 часа ночи с отсутствующим DBID может стать кошмаром.
Ура,
Уильям

Идентификатор базы данных (DBID) — это уникальный номер, который может быть идентифицирован RMAN для выполнения резервного копирования и восстановления при необходимости. В некоторых ситуациях вам может потребоваться знать DBID базы данных, чтобы каталог резервных копий знал, что последующие шаги относятся к конкретной базе данных в RMAN.

В этом посте я покажу вам, как найти DBID, когда:

А. Когда база данных открыта (или подключена)

Когда база данных запущена и подключена к сети, мы можем получить как имя базы данных, так и идентификатор. Предположим, мы смонтировали базу данных. Мы можем обнаружить DBID с помощью SQL*Plus или RMAN.

1. Найти DBID в SQLPLUS

Мы получаем DB_NAME и DBID, запрашивая V$DATABASE .

SQL> conn / as sysdba
Подключен.
SQL> выберите имя, dbid из базы данных v$;

2. Найдите DBID в RMAN

Или мы можем подключиться к базе данных через RMAN.

[oracle@test ~]$ rman target /
.
подключен к целевой базе данных: ORCLCDB (DBID= 3411734329, не открыт)

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

Б. Когда база данных закрыта

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

1. Найти DBID в файлах трассировки и аудита

Мы используем grep для вывода только 10 последних вхождений DBID файлов трассировки.

[oracle@test ~]$ grep -ri "DBID" $ORACLE_BASE/diag/rdbms/$DB_NAME/$ORACLE_SID/trace | хвост

В приведенной выше команде замените $DB_NAME на свою в нижнем регистре.

Кроме того, мы можем искать только 10 самых последних вхождений DBID файлов аудита.

[oracle@test ~]$ grep -ri "DBID" $ORACLE_BASE/admin/$ORACLE_SID/adump | хвост

Если вы по-прежнему ничего не нашли о DBID, давайте продолжим.

2. Найти DBID по Force Nomount

Когда ваша база данных сильно повреждена, вы не можете нормально запустить базу данных, вы можете только принудительно запустить экземпляр NOMOUNT. Это фиктивный экземпляр, который мы можем использовать позже.

[oracle@test ~]$ rman target /
.
подключен к целевой базе данных (не запущен)

RMAN> принудительное запуск nomount;

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

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

[oracle@test ~]$ sqlplus / as sysdba
.
SQL> изменить файл данных системного дампа '/u01/app/oracle/oradata/ORCL/system01.dbf' блок 1;

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

Затем мы проверяем самый последний файл трассировки вашей базы данных и ищем "DB ID fixed-text">$ORACLE_BASE .

[oracle@test ~]$ grep -ri "ID DB Highlight-Text">Db >=0xcb5aef39, Db Name='ORCLCDB'

Эта статья посвящена шагам, требующим восстановления, когда мы извлекаем ИДЕНТИФИКАТОР БАЗЫ ДАННЫХ, выгружая его из файлов данных или онлайновых и архивных журналов повторного выполнения. DBID означает идентификатор базы данных, который является уникальным идентификатором для каждой работающей базы данных Oracle. Он находится в управляющих файлах, а также в заголовке файла данных. Если база данных открыта, вы можете напрямую запросить базу данных v$ и найти DBID.

Это некоторые условия, когда нам требуется DBID для восстановления базы данных

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

  • Управляющий файл был утерян и должен быть восстановлен из резервной копии.
  • Вы используете каталог восстановления.
  • Несколько баз данных, зарегистрированных в каталоге восстановления, имеют общее имя базы данных.
  • Вы получаете сообщение «RMAN-20005: имя целевой базы данных неоднозначно» при попытке восстановить управляющий файл.
  • у вас даже не настроена область мгновенного восстановления ИЛИ она есть, но вы не указали %F в ​​параметре автоматического резервного копирования RMAN;

Я думаю, что сегодня очень сложно оказаться в ситуации, когда требуется знать идентификатор вашей базы данных для восстановления базы данных.
Но, согласно ОП (оригинальный постер), кажется, что это могло произойти: действительно, в этой ветке форума Oracle был задан вопрос, как можно определить идентификатор базы данных (DBID), когда:

  1. экземпляр уже аварийно завершил работу, а управляющие файлы недоступны
  2. Никто не сохранял вывод ежедневного резервного копирования RMAN
  3. Вы используете область мгновенного восстановления, и ваши автоматические резервные копии сохраняются с использованием синтаксиса OMF.

Поэтому, если ваш экземпляр не работает и управляющие файлы недоступны, вы не можете открыть базу данных и запросить V$DATABASE, чтобы узнать DBID.
Я имею в виду, что вы не можете выполнить такой запрос:

Затем, когда вы подключитесь к своему экземпляру с помощью RMAN, он покажет вам идентификатор базы данных…

Более того, если вы не указали формат %F в ​​параметре файла управления автоматическим резервным копированием, я имею в виду что-то вроде:

…ваша база данных сохранит его в формате OMF. Как вы можете прочитать в документации Oracle по этой ссылке
«Все файлы в области быстрого восстановления поддерживаются базой данных Oracle, а связанные имена файлов поддерживаются в формате Oracle Managed Files (OMF)», действительно, ваш управляющий файл автоматического резервного копирования выиграл бесполезно вычитать ваш DBID, используя желаемый формат c-IIIIIIIIII-YYYYMMDD-QQ (где IIIIIIIIII будет идентификатором вашей базы данных).

Итак, как вы можете продолжить? Больше нельзя узнать идентификатор базы данных?

Я предложил просто использовать команду «ALTER SYSTEM DUMP».
Пока вы можете выгружать любые файлы данных, журналы повторов и даже архивные журналы повторов, экземпляр может находиться в режиме NOMOUNT: чтобы получить желаемый DBID, вам нужно только знать точный путь к вашему файлу.

Посмотрите на следующие образцы:

Команда для создания дампа файла данных SYSTEM:

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

Команда для вывода файла данных UNDO:

Снова к тому же файлу трассировки Oracle добавляет дамп запрошенного файла данных UNDO и тот же DBID.

Как насчет того, чтобы сбросить онлайн-журнал повторов?

Всегда в одном и том же файле трассировки можно найти DBID.

Наконец-то даже сброс АРХИВИРОВАННОГО журнала повторов…

… и при просмотре файла трассировки снова отображается DBID.

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

После завершения обновления выполните тот же процесс обновления агентов.

Читайте также: