Oracle получить sid текущей сессии
Этот выпуск посвящен некоторым аспектам проблемы переименования и клонирования базы данных. Начнем с простого - как узнать и изменить идентификатор службы (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, кстати, описано вот здесь.
Copyright © 2003 Oracle Corporation
Имя экземпляра базы данных
Экземпляр базы данных состоит из области 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) и имя базы данных (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, кстати, описано вот здесь.
Copyright © 2003 Oracle Corporation
- Главная /
- Статьи /
- 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 .
Уничтожаем активный сеанс
Читайте также: