Удаление подключенного пользователя из схемы базы данных Oracle 10g

Question

Удаление подключенного пользователя из схемы базы данных Oracle 10g

54

Есть ли лучший способ принудительно отключить всех пользователей от схемы базы данных Oracle 10g, чем перезапустить службы баз данных Oracle?

У нас есть несколько разработчиков, использующих SQL Developer, подключающихся к одной и той же схеме на одном сервере Oracle 10g. Проблема в том, что, когда мы хотим отказаться от схемы для ее восстановления, неизбежно кто-то все еще подключен, и мы не можем отказаться от схемы базы данных или пользователя, пока кто-то все еще подключен.

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

Кто-нибудь знает быстрый способ решить эту проблему?

Joshua Starner 17 сен. 2008, в 19:33

Источник

Теги:

oracle

7 ответов

14

Найти существующие сеансы в БД с помощью этого запроса:

SELECT s.inst_id,
       s.sid,
       s.serial#,
       p.spid,
       s.username,
       s.program
FROM   gv$session s
       JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id
WHERE  s.type != 'BACKGROUND';

вы увидите что-то вроде ниже.

Затем выполните ниже запрос со значениями, извлеченными из полученных выше результатов.

ALTER SYSTEM KILL SESSION '<put above s.sid here>,<put above s.serial# here>';

Пример: ALTER SYSTEM KILL SESSION '93, 943 ';

Chand Priyankara 20 май 2013, в 07:08

7

Мое предложение - это простой анонимный блок:

DECLARE
   lc_username   VARCHAR2 (32) := 'your user name here';
BEGIN
   FOR ln_cur IN (SELECT sid, serial# FROM v$session WHERE username = lc_username)
   LOOP
      EXECUTE IMMEDIATE ('ALTER SYSTEM KILL SESSION ''' || ln_cur.sid || ',' || ln_cur.serial# || ''' IMMEDIATE');
   END LOOP;
END;
/

RLapinski 10 дек. 2013, в 13:58

2

лучше записать оспид перед тем, как убивать сеансы, они могут застрять
user3380585 10 окт. 2014, в 10:51

1

просто используйте SQL:

disconnect; 

conn tiger/scott as sysdba;

LinuxQuestions.org 23 фев. 2012, в 17:40

1

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

tc 23 сен. 2008, в 20:30

2

Может быть проще и менее навязчиво заблокировать пользователя, которого он намеревается удалить, затем прекратить все связанные сеансы этого пользователя, затем отбросить его и создать заново. Не нужно излишне ограничивать доступ другим пользователям.
Mark J. Bobak 23 фев. 2012, в 23:02

0

Только мои два цента: лучший способ (но, вероятно, не самый быстрый в краткосрочной перспективе), вероятно, будет для каждого разработчика работать над собственным экземпляром базы данных (см. правило №1 для работы с базой данных).

Установка Oracle на станции-разработчике стала без проблем с Oracle Database 10g Express Edition.

Mac 19 сен. 2008, в 16:36

0

Только для Windows и некоторых разновидностей Linux.
Peter Bratton 02 окт. 2012, в 20:27
0

Это на самом деле не имеет отношения к вопросу?
Konrads 09 дек. 2016, в 14:58
0

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

Показать ещё 1 комментарий

0

Вы пробовали ALTER SYSTEM KILL SESSION? Получите SID и SERIAL # из V $SESSION для каждого сеанса в данной схеме, затем выполните

ALTER SCHEMA KILL SESSION sid, серийный номер;;

Dave Costa 17 сен. 2008, в 18:38

Ещё вопросы

лучше записать оспид перед тем, как убивать сеансы, они могут застрять
Может быть проще и менее навязчиво заблокировать пользователя, которого он намеревается удалить, затем прекратить все связанные сеансы этого пользователя, затем отбросить его и создать заново. Не нужно излишне ограничивать доступ другим пользователям.
Только для Windows и некоторых разновидностей Linux.
Это на самом деле не имеет отношения к вопросу?
Возможно, это не тот ответ, который искал просящий, и я прекрасно понимаю, почему за него не проголосовали очень сильно, но я думаю, что это очень актуально, учитывая вариант использования, который он специально выдвинул. Несколько разработчиков, работающих над одной и той же базой данных, являются очень плохой идеей, и эта проблема определенно не самая худшая, что может произойти.

Sten Vesterli · Accepted Answer · 2008-09-17T20-29-00.000Z

Чтобы найти сеансы, как использование DBA

select sid,serial# from v$session where username = '<your_schema>'

Если вы хотите убедиться, что только для сеансов, использующих SQL Developer, вы можете добавить and program = 'SQL Developer'. Если вы хотите только убить сеансы, принадлежащие конкретному разработчику, вы можете добавить ограничение на os_user

Затем убейте их

alter system kill session '<sid>,<serial#>'

(например, alter system kill session '39,1232')

Запрос, создающий готовые команды-убийцы, может быть

select 'alter system kill session ''' || sid || ',' || serial# || ''';' from v$session where username = '<your_schema>'

Это приведет к возврату одного оператора убийства за сеанс для этого пользователя - что-то вроде:

alter system kill session '375,64855';

alter system kill session '346,53146';

Я обнаружил, что в нашей среде RAC уничтожение сеанса часто приводило к зависанию, но поиск идентификатора процесса и удаление его из операционной системы всегда работали.
небольшое дополнение - добавьте немедленно к команде: select 'alter system kill session ''' || sid || ',' || serial# || ''' immediate;' from v$session where username = '<your_schema>'; это заставит команду
хороший ответ. Именно то, что я искал.