Oracle получить sid текущей сессии

Обновлено: 19.05.2024

Этот выпуск посвящен некоторым аспектам проблемы переименования и клонирования базы данных. Начнем с простого - как узнать и изменить идентификатор службы (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 :

Остановите экземпляр
Скопируйте все управляющие файлы, журналы повторного выполнения и файлы данных.
Пройдите по файлам .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, кстати, описано вот здесь.

Имя экземпляра базы данных

Экземпляр базы данных состоит из области SGA и процессов ORACLE. Имя экземпляра базы данных указывается в файле инициализации init.ora параметром instance_name.

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

Оракловский системный идентификатор SID (System IDentifier – системный идентификатор) является уникальным именем, которое однозначно идентифицирует экземпляр/базу данных. Хранится в переменной среды ORACLE_SID и используется утилитами и сетевыми компонентами для доступа к базе данных.

Здесь можно почитать, как переименовать базу данных.

Глобальное имя базы данных

Для того, чтобы база данных была уникально идентифицирована в глобальном масштабе используется глобальное имя базы данных. Оно состоит из имени базы данных и домена базы данных. Так как две базы данных в одном домене не могут иметь одинаковые имена, то глобальное имя базы данных будет уникальным.

Имена службы (сервиса) базы данных.

Кроме понятия SID существует также и понятие SERVICE NAME, которые зачастую не различают. Тем не менее, для пользователей база данных ORACLE представляет собой службу (сервис) операционной системы. Имя сервиса (SERVICE_NAME) – это сравнительно новое понятие, введенное начиная с СУБД Oracle 8i. SERVICE_NAME определяет одно или ряд имен для подключения к одному экземпляру базы данных. То есть можно указать несколько имен сервиса, ссылающихся на один экземпляр, с различными настройками. Понятие служба БД используется для логического группирования сеансов с целью иметь обобщенную единицу слежения и управления при использовании общей БД разными приложениями. Службу рекомендуется связывать с набором приложений, объединенных общими свойствами, пороговыми характеристиками или правилами потребления ресурсов СУБД.

Возможные значения SERVICE_NAME указываются в сетевых установках Oracle и регистрируются в качестве службы БД процессом listener.

Стандартный способ получения SID и SERVICE_NAME, который работал до десятой версии СУБД Oracle – это использование утилиты lsnrctl. Для этого достаточно воспользоваться командой services:

В выводе команды мы можем видеть системный идентификатор, он же – SID (Instance), и имя сервиса – SERVICE_NAME (Service). В данном случае они совпадают, но это бывает не всегда.

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

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

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

НАЗНАЧЕНИЕ

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

Для АБД, которым надо найти или изменить 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 :

Остановите экземпляр
Скопируйте все управляющие файлы, журналы повторного выполнения и файлы данных.
Пройдите по файлам .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 .

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

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

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

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

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

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

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

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

Главная /
Статьи /
Oracle /
Дублирование базы данных с помощью RMAN. Часть 1.

Практическое администрирование Oracle - Экземпляр - Уничтожение сеансов

С еанс – это специфическое соединение пользователя к экземпляру Oracle через пользовательский процесс. При работе с выделенным сервером для каждого такого сеанса создается отдельный серверный процесс. Обмен пользователя с экземпляром базы данных происходит через пользовательский процесс на клиентской машине, который в свою очередь через драйвер клиента Oracle Net работает с выделенным серверным процессом, взаимодействующим непосредственно с самим экземпляром Oracle. Иногда возникают ситуации, когда требуется уничтожить какие либо сеансы. Такое обычно такое происходит, когда требуется прервать долго выполняющийся сеанс или возникает необходимость в проведении административных работ с отключением всех сеансов. Так же может понадобиться и просто откатить незафиксированную транзакцию, если за данным сеансом выстроилась большая очередь. Бывают и так называемые “потерянные сеансы”, нуждающиеся в уничтожении. В этой главе мы научимся идентифицировать такие сеансы, уничтожать их, а так же рассмотрим сложности, возникающие при этом процессе.

Идентифицируем сеанс

Параметры получены. Теперь можно приступить к уничтожению сеанса.

Уничтожаем неактивный сеанс

Выполним команду ALTER SYSTEM KILL SESSION для указанного выше сеанса:

Посмотрим состояние сеанса:

Если сеанс неактивный и не содержит незавершенных транзакций, то он помечается со статусом KILLED . Поле PADDR уже не указывает на адрес структуры выделенного серверного процесса. Но серверный процесс не освобождается:

Информация при этом о сеансе из представления v$session исчезает:

Но остаётся в таблице x$ksuse:

Серверный процесс при этом всё ещё существует:

Если пользователь продолжит пытаться выполнять команды, то экземпляр на все дальнейшие попытки будет отвечать ошибкой ORA-01012: not logged on:

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

Уничтожаем сеанс с незафиксированными транзакциями

Если в сеансе имеются незафиксированные транзакции, то при выдаче команды ALTER SYSTEM KILL SESSION происходит откат этих транзакций. Занимается откатом мертвых транзакции фоновый процесс Oracle SMON . Убедимся в этом, выполнив следующий пример:

Теперь попытаемся уничтожить этот сеанс:

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

Это означает, что мёртвая транзакция 0x0006.00a.00000091 была восстановлена процессом SMON. Если же в экземпляре используется параллельное восстановление, то функции отката берёт на себя вновь образующийся от SMON дочерний процесс. Его можно увидеть, если выполнить следующий запрос сразу после уничтожения сеанса:

Выбрано: 1 строка

В данном случае трассировочного файла не образуется, но в журнальном файле Oracle появляется запись вида о попытке параллельного восстановления:

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

Уничтожаем серверный процесс

Иногда бывает, что пользовательское приложение завершается аварийно, вместе с ним аварийно завершается и пользовательский процесс. К примеру, отключите сеть, выгрузите приложение, затем снова включите сеть. Для того чтобы уничтожить такие сеансы, Oracle с периодичностью в минутах задаваемой параметром sqlnet.expire_time, который находится в файле sqlnet.ora посылает по всем соединениям пустые пакеты, которые игнорируются работающими пользовательскими процессами. Если физического соединения нет, то Oracle помечает сеанс как убитый и приступает к его уничтожению. В некоторых случаях данный механизм не срабатывает, и возникают так называемые “потерянные сеансы”, то есть сеансы не связанные с пользовательскими процессами. Такие сеансы могут находиться в неопределённом состоянии долгое время. Обычно они легко уничтожаются с помощью команды ALTER SYSTEM KILL SESSION. Но если выполнение команды не приносит результатов, и сеанс продолжает долгое время, находится в статусе KILLED, то придется вмешаться в уничтожение такого сеанса на уровне операционной системы, то есть уничтожить серверный процесс средствами ОС. Операция эта опасная и делать её надо очень аккуратно, чтобы случайно не уничтожить фоновые процессы экземпляра. Для этого желательно всегда запоминать значение идентификатора SPID серверного процесса относящегося к сеансу. Если же значение поля PADDR в представлении v$session уже не соотноситься с адресом в поле ADDR представления v$process , то серверный процесс придется искать приблизительно. В Unix это можно сделать с помощью команды ps , примерно сравнивая время соединения сеанса в поле logon_time представления v$session со временем образования процесса в колонке STARTED результата выполнения команды ps.

В системе Windows сеансы существуют в виде потоков. Поэтому определить такой сеанс будет сложнее. Чтобы облегчить задачу можно выполнить запрос к представлению v$process, который покажет все процессы, у которых значения поля ADDR не соответствует ни одному значению в поле PADDR представления v$session:

Здесь мы видим такой процесс со значением идентификатора процесса в операционной системы SPID равным 652. Попробуем уничтожить данный серверный процесс. В системе Windows это делается с помощью утилиты командной строки orakill:

В Unix с помощью команды kill -9 spid .

Уничтожаем активный сеанс

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