Global database name oracle что это

Обновлено: 05.07.2024

Файл параметров инициализации имеющий имя init.ora, собственно является основным средством настройки БД. Он представляет из себя обычный ASCII файл, содержащий ряд параметров, которые БД, использует при старте и последующем разворачивании в ОС. Правда здесь есть один нюанс, сама БД ищет, файл инициализации с именем initSID.ora. Где SID, напомню, если кто забыл, это служебное имя вашего экземпляра БД. В нашем случае, если вы инсталлировали БД, как я вам предлагал, это будет PROBA (например, моя экспериментальная БД имеет в качестве SID значение HOME. Не самое удачное решение, хотя она у меня уже скоро развалится, и я ее переделаю, а за одно выберу другое имя!). Так вот ваш файл инициализации БД будет находиться в каталоге $ORACLE_HOME\DATABASE, $ORACLE_HOME - это в вашем случае каталог С:\Oracle\Ora81, значит в совокупности получается C:\Oracle\Ora81\DATABASE. Там должен лежать файл с именем initPROBA.ora, загляните что у него внутри, должно быть что-то вроде:

Вот теперь надеюсь ясно, параметр IFILE просто указывает вашему экземпляру БД, где искать именно свой, а не чей попало, файл инициализации. Найдя этот файл ваша БД, счастливо стартует и начинает свою трудовую деятельность! Параметр IFILE вообще-то и применяется для лучшего структурирования вашего севера Oracle! А вот в каталоге $ORACLE_HOME\dbs, есть еще один файл init.ora, если его внимательно изучить, то можно настроить любую БД Oracle в различных вариантах исполнения. Малая, средняя, крупная БД, ну и т. д. А теперь давайте заглянем внутрь вашего, файла init.ora. Можно увидеть примерно следующее:

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

Это собственно и есть тот самый SID, вашего экземпляра БД. Экземпляров, может быть, много и у каждого свой уникальный SID!

А это имя сервиса вашего экземпляра БД, то есть два предыдущих параметра вместе. Пока все понятно?

Идем дальше! Собственно все параметры инициализации вашего экземпляра БД можно просмотреть через представление v$parameter. Таких "представлений" в самой БД сотни. С их помощью о вашем экземпляре, можно узнать все. Именно их применяют в своей работе люди, гордо носящие имя Администраторы БД! Можно сказать, что один из них, ваш покорный слуга, так как пару сотен "представлений" я уже изучил! Давайте откроем SQLPlus и дадим такой запрос, естественно воспользовавшись знаниями об однотабличных запросах из прошлых шагов:

Может кто-нибудь объяснить мне, в чем разница SID, имени БД, домена БД, глобального имени базы данных, имени службы, псевдонима службы и имени экземпляра в Oracle?

SID = идентифицирует экземпляр базы данных (имя базы данных + номер экземпляра). Поэтому, если имя вашей базы данных - somedb, а номер вашего экземпляра - 3, тогда ваш SID - somedb3.

Имя БД = Имя базы данных (база данных может совместно использоваться несколькими экземплярами)

Имя службы = «соединитель» для одного или нескольких экземпляров. Часто полезно создавать дополнительные имена служб в среде RAC, поскольку служба может быть модифицирована для использования определенных SID в качестве первичных или вторичных соединений или для того, чтобы вообще не использовать определенные SID.

Псевдоним службы = псевдоним имени службы (как CNAME и т. Д.). Скажем, вы делаете имя своего сервиса чем-то значимым для dba, но, возможно, это немного эзотерично Создайте псевдоним службы и назовите его так, чтобы он имел смысл для пользователя.

Имя экземпляра = такое же как SID

при каких обстоятельствах у вас есть номер экземпляра? это только с RAC?

То, как вы описываете SID, - это только поведение DEFAULT в конфигурации RAC. SID (== имя_экземпляра) - это просто имя вашего экземпляра.

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

База данных имеет имя, db_name и (необязательно) домен (db_domain) -> вместе global_db_name. Теперь представьте, что вы реплицируете (DataGuard) свою базу данных. Вы хотели бы оставить имя DB_name таким же, верно? (Я имею в виду: с точки зрения данных, это ЖЕ база данных) Но тогда как определить две «версии» вашей базы данных? Введите 'DB_UNIQUE_NAME' . Да, это сбивает с толку .

Моя личная практика - называть INSTANCE именем db_unique_name в настройке DataGuard и придерживаться RAC-имен (db_name + Instance_Number) в настройке RAC. Затем, db_unique_names, которые я составляю, обычно похожи на db_name + 1-буквенный суффикс (MYDBa MYDBb и т. Д.)

SID является экземпляром. Лучше избегать использования термина «экземпляр базы данных», просто «экземпляр».

«SID = идентифицирует экземпляр базы данных (имя базы данных + номер экземпляра)» неверно. «Экземпляр, это экземпляр программного обеспечения СУБД» неправильно. Удаленная или установленная СУБД - это просто СУБД.

«Домен БД = обычно такой же, как домен вашей компании» следует избегать. У меня возникла проблема с использованием домена, и проблемы исчезли, если не использовать домен.

«Глобальное имя базы данных = имя базы данных + домен базы данных» также неверно. Глобальное имя базы данных - это имя службы. Это так просто.

«SID = идентифицирует экземпляр базы данных (имя базы данных + номер экземпляра). Поэтому, если имя вашей базы данных - somedb, а номер вашего экземпляра - 3, то ваш SID - somedb3». неправильно. Нет такой привязки личности или имени.

Этот выпуск посвящен некоторым аспектам проблемы переименования и клонирования базы данных. Начнем с простого - как узнать и изменить идентификатор службы (SID) и имя базы данных (DB_NAME). Последний раз Том Кайт вернулся к этому вопросу 20 августа 2002 года.

Что такое SID, как его узнать и как изменить

Ответ Тома Кайта

Изменить его сложнее, чем кажется. Я знаю, что вы работаете в ОС Unix, поэтому следующая последовательность шагов для изменения SID (или имени базы данных) в Unix - для вас. В NT последовательность шагов - немного другая.

Как найти sid -- с помощью оператора select instance from v$thread .

НАЗНАЧЕНИЕ

Здесь описано, как найти и изменить имя базы данных ( db_name ) или ORACLE_SID для экземпляра, не пересоздавая базу данных.

ДЛЯ КОГО ЭТА ЗАМЕТКА

Для АБД, которым надо найти или изменить db_name или ORACLE_SID .

Чтобы найти текущие значения DB_NAME и ORACLE_SID:

Выполните запросы к представлениям v$database и v$thread .

Если ORACLE_SID = DB_SID и db_name = DBNAME :

Чтобы найти текущее значение ORACLE_SID :

Чтобы найти текущее значение DB_NAME :

Изменение базы данных для работы с новым ORACLE_SID :

  1. Остановите экземпляр
  2. Скопируйте все управляющие файлы, журналы повторного выполнения и файлы данных.
  3. Пройдите по файлам .profile , .cshrc , .login , oratab , tnsnames.ora и задайте переменной среды ORACLE_SID новое значение.

Например, пройдите по всем каталогам и выполните grep ORACLE_SID *

  • init<sid>.ora (или используйте для задания файла параметров инициализации файл pfile .)
  • управляющий файл (файлы). Это не обязательно, если вы не переименовываете управляющие файлы и используете параметр control_files . Параметр control_files устанавливается в файле init<SID>.ora или в файле, на который ссылается в нем параметр ifile . Проверьте, что параметр control_files не указывает на старые имена управляющиъ файлов, если вы их переименовали.
  • crdb<sid>.sql и crdb2<sid>.sql , Это не обязательно, пеоскольку эти файлы используются только при создании базы данных.
  • startup<sid>.sql . Это не обязательно. На некоторых платформах этот файл может находиться в каталоге $ORACLE_HOME/rdbms/install . Проверьте, что содержимое этого файла не ссылается на старые файлы init<SID>.ora , которые вы переименовали. Этот файл упрощает процесс запуска с сервера базы данных в исключительном режиме ( startup exclusive ).

Будет выдан запрос архивного файла журнала повторного выполнения. После применения текущего файла журнала базу данных, возможно, удастся открыть. Но, это НЕ ГАРАНТИРОВАНО . Если после применения текущего файла журнала повторного выполнения база данных не открывается, весьма вероятно, придется повторить все с начала, предварительно нормально остановив старую базу данных.

Чтобы найти список активных журнальных файлов:

Cколько АБД Oracle надо, чтобы поменять лампочку. Комментарий от 13 сентября 2001 года

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

Смысл реляционной модели - нормализация; если проще - устранение избыточных данных. А что мы имеем - SID в десятке мест?

Ответ Тома Кайта

Чтобы было просто -- не меняйте SID .

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

НА САМОМ ДЕЛЕ, мы сталкиваемся с попыткой ИЗМЕНИТЬ ПЕРВИЧНЫЙ КЛЮЧ.

Это, на самом деле, ПРЕКРАСНАЯ демонстрация особенностей реляционной модели. Первичным ключом для базы данных является SID. Вы пытаетесь изменить первичный ключ (чего в реляционных базах данных делать КРАЙНЕ НЕ РЕКОМЕНДУЕТСЯ) и реализовать действие on update cascade .

Так что, даже при наличии ОДНОГО внешнего ключа, пробюлема будет аналогичной. Если вы когда-нибудь изменяли значение первичного ключа, вам приходилось делать то же самое (находить все внешние ключи и изменять их соответственно).

Почему вы считаете изменение SID "простой вещью" (мне этот процесс кажется весьма мутным -- мне ни разу не приходилось самому это делать за 15 лет).

Комментарий от 1 марта 2001 года

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

Ответ Тома Кайта

например: получаем 7 значений sid, работающих сечас на моей тестовой машине -- ora_pmon_$ORACLE_SID

Если вы работате не на сервере, sid просто не имеет значения, - вам нужна запись tns в файле tnsnames.ora .

На NT посмотрите список служб Oracle в Панели управления.

Оригинал обсуждения этого вопроса можно найти здесь.

Изменение SID на платформе Windows, кстати, описано вот здесь.

Copyright © 2003 Oracle Corporation

  • Главная /
  • Статьи /
  • Oracle /
  • Практическое администрирование Oracle - Ожидание Library cache pin. Часть 1.

ORA_DATABASE_NAME

Что должен возвращать следующий запрос?

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

Прежде чем приступить к непосредственному практическому изучению ora_database_name, вспомним, как трактуется она в документации Oracle. Единственное упоминание о ней мы найдем только в книге Oracle Database Application Developer's Guide - Fundamentals в разделе Coding Triggers, где описывается, что она принадлежит к группе функций для идентификации атрибутов происшедшего события. Таких разнообразных функций на самом деле около тридцати, они все начинаются с префикса ora_ и используются в основном в системных триггерах. Судя по документации, наша функция ora_database_name должна выводить имя базы данных. Проверим, действительно ли это так:

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

А вот просмотр доменной вызовет трудности. По идее эти части должны определяться на уровне создания инициализационными параметрами базы данных db_name и db_domain. Посмотрим их значения:

Если с параметром db_name всё понятно, то параметр db_domain ничего не содержит. Откуда же тогда взялась эта вторая часть глобального имени? Скорее всего, это значение по умолчанию, так как db_domain до создания базы имел значение NULL. Теперь изменение вышеприведенных параметров ни как не повлияет на состав глобального имени. Если изменить первый параметр, база просто не откроется, а изменение значения второго параметра будет просто проигнорировано.

Ясно, что хоть эти параметры и участвуют в организации глобального имени на этапе создания базы данных, но они не являются источником для функции, которую мы рассматриваем. На самом деле ora_database_name это всего лишь публичный синоним, указывающий на функцию database_name, которая в свою очередь состоит из единственного вызова одноимённой функции database_name пакета dbms_standard. В свою очередь функция пакета, использует внешнюю С функцию.

Казалось, след потерян, доступа к функции нет. Но не всё так плохо. Есть одно системное представление global_name, содержимое которого идентично результату выполненного ранее нами запроса. Может оно приведёт нас к источнику нашей функции:

Данное представление ссылается на строку с именем GLOBAL_DB_NAME в таблице props$ схемы sys. Эта таблица относится к словарю и содержит некоторые значения фиксированных параметров базы данных. Попробуем изменить это параметр прямо в таблице и посмотреть, изменится ли значение возвращаемое функцией ora_database_name:

Выводимый результат функции не изменился. Он изменится только после перезагрузки экземпляра. Но уже сейчас ясно, что строка GLOBAL_DB_NAME таблицы props$ не связана напрямую с результатом, который выводит функция ora_database_name.

И так, похоже, мы нашли способ, который изменит выводимое значение глобального имени. Но правка системной таблицы Oracle не самый лучший вариант. К счастью в Oracle есть команда ALTER DATABASE RENAME GLOBAL_NAME, которая предназначена для изменения глобального имени базы данных. Попробуем с её помощью изменить наше глобальное имя:

Как видим, функция ora_database_name стала сразу выдавать необходимый нам результат, при этом нам не понадобилось даже перезагружать экземпляр. Правда в этом способе изменения глобального имени есть небольшая оговорка. Например, если у предыдущего имени есть доменная составляющая, то отбросить её с помощью ALTER DATABASE в новом имени уже не получиться:

Придётся комбинировать эти два способа:

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

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

И так, результат достигнут. Мы узнали, что собой представляет функция ora_database_name и как можно изменить возвращаемое ею содержимое. Теперь можно сделать и выводы:

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