核心业务上线前数据库的重要工作
1、环境清理，删除测试数据，用于测试的环境配置
2、权限回收，检查不合理的用户权限，不需要的dba权限，非必要的数据库连接
3、压力测试总结
4、参数优化报告
5、基础信息统计
6、备份恢复测试报告
7、性能基线报告
分类 ORACLE 下的文章
logic dg 查询常用语句。
客户单位部署了2套logic dg ，考虑到可能会查询，转载备用。
1.日志应用的启动和关闭
ALTER DATABASE STOP LOGICAL STANDBY APPLY; ---停止应用，等待事务完成
ALTER DATABASE ABORT LOGICAL STANDBY APPLY;--不等待事务完成就停止
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ---实时
ALTER DATABASE START LOGICAL STANDBY APPLY; --非实时
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE SKIP FAILED TRANSACTION; --实时应用并跳过失败的事务
如何知道是否开启了实时应用呢？可以查询V$LOGSTDBY_STATE视图或查询是否有lsp进程。
SQL> SELECT * FROM V$LOGSTDBY_STATE;
PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE
------------ ---------- ------------------ -----------------------------------------
1480747539 1 Y APPLYING
[oracle@rhel6_lhr oraljdg]$ ps -ef|grep -i ora_lsp
6oracle 20450 1 0 15:22 ? 00:00:00 ora_lsp0_oraljdg
2.查看日志文件的应用情况
COLUMN DICT_BEGIN FORMAT A15;
COLUMN FILE_NAME FORMAT A50;
SET NUMF 9999999;
COL FCHANGE# FORMAT 9999999999999;
COL NCHANGE# FOR 999999999999999999999;
SET LINE 200
SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#,
NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, DICT_BEGIN AS BEG,
DICT_END AS END, THREAD# AS THR#, APPLIED
FROM DBA_LOGSTDBY_LOG
ORDER BY THREAD#,SEQUENCE#;
SET LINE 9999 PAGESIZE 9999
COL FILE_NAME FORMAT A120
SELECT THREAD#,SEQUENCE#, FILE_NAME, APPLIED, TIMESTAMP
FROM DBA_LOGSTDBY_LOG D
WHERE D.SEQUENCE# >=(SELECT MAX(SEQUENCE#)-3 FROM DBA_LOGSTDBY_LOG NB WHERE NB.THREAD#=D.THREAD# AND NB.APPLIED='YES' )
ORDER BY THREAD#,D.SEQUENCE#;
3.查看备库SQL Apply的进度
SQL> SELECT LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;
LATEST_SCN MINING_SCN APPLIED_SCN LATEST_TIME MINING_TIME APPLIED_TIME
---------- ---------- ----------- ------------------- ------------------- -------------------
8895794846 8895316681 8895316680 2010-05-18 16:27:08 2010-05-18 16:03:54 2010-05-18 16:03:54
4.查看备库是否有任何DDL/DML语句未成功应用
COL EVENT_TIMESTAMP FORMAT A30
COL EVENT FORMAT A40
COL EVENT_STATUS FORMAT A80
SELECT A.EVENT_TIME,
A.CURRENT_SCN,
A.COMMIT_SCN,
XIDUSN,
XIDSLT,
XIDSQN,
TO_CHAR(EVENT) EVENT,
A.STATUS_CODE,
STATUS EVENT_STATUS
FROM DBA_LOGSTDBY_EVENTS A
WHERE A.EVENT_TIME >= SYSDATE - 10 / 1660
ORDER BY A.EVENT_TIME ;
5.查看备库SQL Apply的状态
COL REALTIME_APPLY FORMAT A15
COL STATE FORMAT A20
SELECT * FROM V$LOGSTDBY_STATE;
PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE
------------ ---------- --------------- ---------------
262089084 1 Y APPLYING
注意STATE列，该列可能有下述的几种状态：
INITIALIZING：LogMiner SESSION已创建并初始化
LOADING DICTIONARY：SQL应用调用LogMiner字典
WAITING ON GAP：SQL应用正在等待日志文件，可能有中断
APPLYING：SQL应用正在工作
WAITING FOR DICTIONARY LOGS：SQL应用正在等待LogMiner字典信息
IDLE：SQL应用工作非常出色，处于空闲状态
SQL APPLY NOT ON：没有开启应用
6.取消部分对象或事务的同步
可以利用DBMS_LOGSTDBY.SKIP存储过程跳过特定表或特定用户的DML事务或部分DDL语句。这些跳过的对象或事务可以通过视图DBA_LOGSTDBY_SKIP和DBA_LOGSTDBY_SKIP_TRANSACTION查看。
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'VIEW');
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'PROFILE');
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DATABASE LINK');
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'CREATE VIEW');
EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DROP VIEW');
EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'%', OBJECT_NAME=>'%', PROC_NAME=>NULL);
EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'LHR', OBJECT_NAME=>'%', PROC_NAME=>NULL);
EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'MDSYS', OBJECT_NAME=>'%', PROC_NAME=>NULL);
EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION (3, 3, 827); --(XIDUSN = 3, XIDSLT = 3, XIDSQN = 827)
SELECT EVENT, STATUS,'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND A.EVENT_TIME >= SYSDATE - 60 / 1660;
SELECT 'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND A.EVENT_TIME >= SYSDATE - 10 / 1660;
SELECT * FROM DBA_LOGSTDBY_SKIP;
SELECT * FROM DBA_LOGSTDBY_SKIP_TRANSACTION;
7.增加apply进程个数
如果Apply进程过于繁忙，那么可以增加Apply进程个数。以下命令调整为20，默认为5个:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',20);
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
8.处理从主库接收到的归档文件
逻辑DG在应用完归档日志后会自动删除该归档文件，这一特性是由逻辑DG中的2个参数控制的，它们分别为LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET。
LOG_AUTO_DELETE的值默认为TRUE，表示逻辑DG在应用完归档日志后会自动删除该归档文件，默认24小时之后删除（由参数LOG_AUTO_DEL_RETENTION_TARGET控制）。如果希望禁用自动删除的功能，那么可以执行下列语句：
EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);
在告警日志中会有类似如下的记录：
Fri Jul 27 13:48:53 2018
LOGMINER: Log Auto Delete - deleting: /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf
Deleted file /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf
在某些情况下确实需要禁用归档文件的自动删除功能，例如逻辑DG需要执行Flashback Database操作，如果你想恢复到之前的某个时间点，然后再接着应用，那么就必须要有该时间点后对应的归档。假如LOG_AUTO_DELETE为TRUE的话，应用过的归档已经被删除，想回都回不去。
参数LOG_AUTO_DEL_RETENTION_TARGET表示逻辑DG在应用完归档日志后的多长时间之后再自动删除该归档文件。该参数仅在LOG_AUTO_DELETE设置为TRUE之后才起作用，默认值为1440分钟，即24小时，可以通过以下命令修改该值的大小：
1exec DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DEL_RETENTION_TARGET', 1);
以上命令表示归档日志被应用完之后，再过1分钟才会自动删除该归档日志。需要注意的是，这些设置仅适用于从主库传递过来的归档文件归档到的位置不是闪回恢复区。如果正在使用闪回恢复区，那么这些从主库传递过来的归档文件将不再根据参数LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET的值做处理。
如果禁止了逻辑DG归档文件的自动删除功能，那么一定要有相应的其他解决方案，不能说取消了自动删除功能，之后逻辑Standby数据库接收到的Standby归档文件就不再管它，这肯定会产生问题，最起码要考虑到逻辑Standby数据库的存储空间是有限的。
逻辑Standby数据库接收到的归档文件并不会显示在V$ARCHIVED_LOG视图中，因此以为通过RMAN中的配置自动删除这些文件的希望也是会落空的。对于这类文件的删除，正确的删除方法通常会按照如下步骤操作：
首先执行DBMS_LOGSTDBY.PURGE_SESSION，该过程会检查当前所有接收到的归档日志文件，对于那些已经应用过，不再需要（这里是当前不再需求，未来是否有可能需要就得由DBA来决定了）的文件进行标记，例如：
EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;
然后，查询数据字典DBA_LOGMNR_PURGED_LOG，所有被DBMS_LOGSTDBY. PURGE_SESSION标记不再需要的日志都会记录在这里，例如：
SELECT * FROM DBA_LOGMNR_PURGED_LOG;
该字典只有一列，即归档文件的实际路径。最后根据显示的路径找到这些文件，然后在操作系统中删除即可。
9.调整PREPARER（调制机）的进程数
如果备库上有很多事务在等待Apply，但是还有空闲的Applier进程，且已经没有idle状态的PREPARER（调制机）进程，这时需要增加PREPARER的进程数。以下命令调整为4个，默认为1个:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS',4);
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
10.调整MAX_SGA，防止Paged out
通过以下SQL可以查询到是否发生了Paged out：
SQL>select value bytes from v$logstdby_stats where name='bytes paged out';
如果以上查询结果在增长，那么查看当前MAX_SGA的大小:
SQL>select value from v$logstdby_stats where name like 'maximum SGA for LCR cache%';
VALUE
---------------------------------------------------------------
30
可以增大MAX_SGA:
SQL>alter database stop logical standby apply;
SQL>execute dbms_logstdby.apply_set('MAX_SGA',1000);
SQL>alter database start logical standby apply immediate;
逻辑备库需要将Redo记录解析成LCR（Logical Change Records），会在Shared Pool里分配一部分空间来作为LCR Cache，如果Cache太小，就会像OS的虚拟内存管理一样，需要做page out，这会严重影响应用日志的性能。在默认情况下，LCR Cache为Shared Pool的四分之一，最少不少于30M（默认为30M，最大可以设置到4096M），否则SQL Apply不能启动。如果机器的内存足够，建议将LCR Cache尽量设大一点，当然，同时Share Pool也要足够大。如果机器内存有限，那么可以考虑将Buffer Cache减少一点来给LCR Cache腾出空间。
11.调整事务应用方式
默认情况下逻辑Standby端事务应用顺序与Primary端提交顺序相同。如果希望逻辑Standby端的事务应用不要按照顺序的话，那么可以按照下列的步骤操作：
①停止SQL应用:
SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;
②允许事务不按照Primary的提交顺序应用：
SQL>EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER','FALSE');
③重新启动SQL应用
SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;
恢复逻辑Standby按照事务提交顺序应用的话，按照下列步骤：
①还是先停止SQL应用：
SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;
②重置参数PRESERVE_COMMIT_ORDER的初始值：
SQL>EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');
③重新启动SQL应用：
SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;
————————————————
版权声明：本文为CSDN博主「小麦苗DBA宝典」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lihuarongaini/article/details/104586179
execute dbms_logstdby.skip(stmt => 'DML',schema_name => '%', object_name => '%');
stmt的取值可以是：
http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10802/d_lsbydb.htm#997290
// 跳过的内容记载在下面
select * from dba_logstdby_skip
// 停止apply
alter database stop logical standby apply;
alter database abort logical standby apply;
// 执行apply
alter database start logical standby apply;
// 实时apply
alter database start logical standby apply immediate;
// 跳过错误，在dba_logstdby_skip表中，ERROR列为Y
execute dbms_logstdby.skip_error('NON_SCHEMA_DDL');
// 执行apply，跳过失败的事务
alter database start logical standby apply skip failed transaction;
// 设置参数，是否记录跳过错误
exec dbms_logstdby.apply_set('RECORD_SKIP_ERRORS','FALSE');
// 设置参数，是否记录跳过DDL
exec dbms_logstdby.apply_set('RECORD_SKIP_DDL','FALSE');
// 在备库上关掉dataguard，备库可写
alter database guard none;
// 在备库上启用dataguard，备库不可写
alter database guard all;
// 官方文档
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10823/toc.htm
//执行某个表不通过，手工同步表
alter database stop logical standby apply;
// 创建DBLINK指向主库，然后同步创建表
exec dbms_logstdby.instantiate_table('EYGLE','SALES','dblink_name');
alter database start logical standby apply;
// 手工添加备库的日志
$ cp /u01/arch/WENDING/1_22751_666200636.arc /u04/arch/WDSTD/log_1_22751_666200636.arc
SQL> alter database register logical logfile '/u04/arch/WDSTD/log_1_22751_666200636.arc';
or
SQL> alter database register or replace logical logfile '/u04/arch/WDSTD/log_1_22751_666200636.arc';
//查看最后的进度
select LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME from V$LOGSTDBY_PROGRESS;
// 监控同步进度的脚本
SELECT * FROM dba_logstdby_log;
select * from dba_logstdby_events order by event_time desc;
select LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME from V$LOGSTDBY_PROGRESS;
select LOGSTDBY_ID,type,status process_status from v$logstdby_process;
select * from v$logstdby_state;
select * from v$dataguard_status order by timestamp desc;
// 增加apply的进程数
ALTER DATABASE STOP LOGICAL STANDBY APPLY; --- Stop SQL Apply
EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20); --- 调整apply进程数为20，默认为5个
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; --- Start real-time Apply
// 停止apply时，如果当前正在应用，会等待执行后才停止
// 下面的命令可以重复执行，如果执行提示stop，则意味着正在apply还没有结束，等结束后重新执行即可
ALTER DATABASE START LOGICAL STANDBY APPLY;
————————————————
版权声明：本文为CSDN博主「wonder4」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wonder4/article/details/5630658
查看用户是否具有dba权限。
系统上线前，发现有业务用户将表建到了system的系统表空间用户下，建到了非默认表空间下。甚至有发现把集群的数据文件创建到了本地目录中的情况。
因此，业务系统上线前，应该首先检查数据库的权限是否合理，是否有不按规划的情况，及时治理，然后再进行清库和导入数据。防止留下隐患。
查看Oracle用户的权限或角色
一、查看用户
1.查看所有用户：
select * from dba_users;
select * from all_users;
select * from user_users; //查看当前用户
二、查看角色
1.当前用户被激活的全部角色
select * from session_roles;
2.当前当前用户被授予的角色
select * from user_role_privs;
3.全部用户被授予的角色
select * from dba_role_privs;
4、查看某个用户所拥有的角色
select * from dba_role_privs where grantee='用户名';
5、查看某个角色所拥有的权限
select * from dba_sys_privs where grantee='CONNECT';
6.查看所有角色
select * from dba_roles;
三、查看权限
1.基本权限查询：
select * from session_privs; --当前用户所拥有的全部权限
select * from user_sys_privs;--当前用户的系统权限
select * from user_tab_privs;--当前用户的对象权限
select * from dba_sys_privs ;--查询某个用户所拥有的系统权限
select * from role_sys_privs;--查看角色(只能查看登陆用户拥有的角色)所包含的权限
查看用户的系统权限(直接赋值给用户或角色的系统权限)
select * from dba_sys_privs;
select * from user_sys_privs;
2.查看用户的对象权限：
select * from dba_tab_privs;
select * from all_tab_privs;
select * from user_tab_privs;
3.查看哪些用户有sysdba或sysoper系统权限(查询时需要相应权限)
select * from v$pwfile_users;
扩展
1、以下语句可以查看Oracle提供的系统权限
select name from sys.system_privilege_map
2、查看一个用户的所有系统权限(包含角色的系统权限)
select privilege from dba_sys_privs where grantee='SCOTT'
union
select privilege from dba_sys_privs where grantee in (select granted_role from dba_role_privs where grantee='SCOTT' );
3、 查询当前用户可以访问的所有数据字典视图。
select * from dict where comments like '%grant%';
4、显示当前数据库的全称
select * from global_name;
问题 1：如何查询一个角色包括的权限？
a.一个角色包含的系统权限
select * from dba_sys_privs where grantee='角色名'
select * from dba_sya_privs where grantee='COONNECT'; connect要大写
另外也可以这样查看：
select * from role_sys_privs where role='角色名'
b.一个角色包含的对象权限
select * from dba_tab_privs where grantee='角色名'
问题 2：Oracle究竟有多少种角色？
select * from dba_roles;
问题 3：如何查看某个用户，具有什么样的角色？
select * from dba_role_privs where grantee='用户名'
问题4：查看哪些用户具有DBA的角色
select grantee from dba_role_privs where granted_role='DBA';
杀锁定会话
数据库锁表分析
1、会话1 update Scott.emp set deptno=10;
2、会话2 update scott.emp set deptno=30;
查询是否存在锁定
select s1.INST_ID,
s1.username || '@' || s1.machine || ' (SID=' || s1.sid ||
' ) is blocking ' || s2.username || '@' || s2.machine || ' ( SID=' ||
s2.sid || ' ) ' AS blocking_status
from gv$lock l1, gv$session s1, gv$lock l2, gv$session s2
where l1.INST_ID = s1.INST_ID
and s1.INST_ID = s2.INST_ID
and s2.INST_ID = l2.INST_ID
and s1.sid = l1.sid
and s2.sid = l2.sid
and l1.BLOCK = 1
and l2.request > 0
and l1.id1 = l2.id1
and l2.id2 = l2.id2;
19:22:53 SQL> select s1.INST_ID,
19:24:50 2 s1.username || '@' || s1.machine || ' (SID=' || s1.sid ||
19:24:50 3 ' ) is blocking ' || s2.username || '@' || s2.machine || ' ( SID=' ||
19:24:50 4 s2.sid || ' ) ' AS blocking_status
19:24:50 5 from gv$lock l1, gv$session s1, gv$lock l2, gv$session s2
19:24:50 6 where l1.INST_ID = s1.INST_ID
19:24:50 7 and s1.INST_ID = s2.INST_ID
19:24:50 8 and s2.INST_ID = l2.INST_ID
19:24:50 9 and s1.sid = l1.sid
19:24:50 10 and s2.sid = l2.sid
19:24:50 11 and l1.BLOCK = 1
19:24:50 12 and l2.request > 0
19:24:50 13 and l1.id1 = l2.id1
19:24:50 14 and l2.id2 = l2.id2;
INST_ID
----------
BLOCKING_STATUS
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1
SYS@localhost.localdomain (SID=16 ) is blocking SYS@WORKGROUP\LAPTOP-5RF2B7J0 ( SID=15 )
查询update后未提交的会话
SELECT
A.SID,
A.SERIAL#,
A.USERNAME,
A.EVENT,
A.WAIT_CLASS,
A.SECONDS_IN_WAIT,
A.PREV_EXEC_START,
B.LOCKED_MODE,
C.OWNER,
C.OBJECT_NAME,
C.OBJECT_TYPE
FROM
V$SESSION A
INNER JOIN V$LOCKED_OBJECT B ON A.SID = B.SESSION_ID
INNER JOIN DBA_OBJECTS C ON B.OBJECT_ID = C.OBJECT_ID
WHERE
A.WAIT_CLASS = 'Idle'
AND A.SECONDS_IN_WAIT >10/SESSION空闲后一段时间还锁定的才算有问题,这里随便给了个数值10秒/
19:27:05 SQL> SELECT
19:27:07 2 A.SID,
19:27:07 3 A.SERIAL#,
19:27:07 4 A.USERNAME,
19:27:07 5 A.EVENT,
19:27:07 6 A.WAIT_CLASS,
19:27:07 7 A.SECONDS_IN_WAIT,
19:27:07 8 A.PREV_EXEC_START,
19:27:07 9 B.LOCKED_MODE,
19:27:07 10 C.OWNER,
19:27:07 11 C.OBJECT_NAME,
19:27:07 12 C.OBJECT_TYPE
19:27:07 13 FROM
19:27:07 14 V$SESSION A
19:27:07 15 INNER JOIN V$LOCKED_OBJECT B ON A.SID = B.SESSION_ID
19:27:08 16 INNER JOIN DBA_OBJECTS C ON B.OBJECT_ID = C.OBJECT_ID
19:27:08 17 WHERE
19:27:08 18 A.WAIT_CLASS = 'Idle'
19:27:08 19 AND A.SECONDS_IN_WAIT >10;
SID SERIAL# USERNAME EVENT WAIT_CLASS SECONDS_IN_WAIT PREV_EXEC_START LOCKED_MODE OWNER OBJECT_NAME OBJECT_TYPE
------ ---------- -------------------- --------------------------------------------- ---------------------------------------------------------------- --------------- ------------------- ----------- ---------- ------------------------------ -------------------
16 61 SYS SQL*Net message from client Idle 38 2021-12-15 19:26:31 3 SCOTT DEPT TABLE
16 61 SYS SQL*Net message from client Idle 38 2021-12-15 19:26:31 3 SCOTT EMP TABLE
Elapsed: 00:00:00.06
----------查看被锁对象
set lin 400 pages 49999
col USERNAME for a15
col owner for a15
col OBJECT_NAME for a35
col PROGRAM for a35
col PROCESS for a15
select a.LOCKED_MODE,a.inst_id,b.owner,b.object_name,a.object_id,a.session_id,c.serial#,c.username,c.sql_id,c.PROCESS ,c.PROGRAM
from gv$locked_object a, dba_objects b,gv$session c
where a.object_id=b.object_id and c.sid=a.session_id;
19:32:51 SQL> set lin 400 pages 49999
19:33:07 SQL> col USERNAME for a15
19:33:07 SQL> col owner for a15
19:33:07 SQL> col OBJECT_NAME for a35
19:33:07 SQL> col PROGRAM for a35
19:33:07 SQL> col PROCESS for a15
19:33:07 SQL> select a.LOCKED_MODE,a.inst_id,b.owner,b.object_name,a.object_id,a.session_id,c.serial#,c.username,c.sql_id,c.PROCESS ,c.PROGRAM
19:33:07 2 from gv$locked_object a, dba_objects b,gv$session c
19:33:07 3 where a.object_id=b.object_id and c.sid=a.session_id;
LOCKED_MODE INST_ID OWNER OBJECT_NAME OBJECT_ID SESSION_ID SERIAL# USERNAME SQL_ID PROCESS PROGRAM
----------- ---------- --------------- ----------------------------------- ---------- ---------- ---------- --------------- ------------------ --------------- -----------------------------------
3 1 SCOTT DEPT 87106 15 9 SYS 022scd5v03tnp 23708:31696 navicat.exe
3 1 SCOTT DEPT 87106 16 61 SYS 19093 sqlplus@localhost.localdomain (TNS
V1-V3)
alter system kill session 'sid,serial#'
oracle 进程分析
操作背景：
压力测试期间，发现一个进程未执行任何sql，在V$SQL中未找到sql_id,因此无法判断阻塞原因，需要通过跟踪进程进行分析
操作如下：
1、查询该阻塞进程的spid
SQL> select spid from v$process where addr in (select paddr from v$session where sid='15');
SPID
------------------------
3417
2、oracle debug
SQL>oradebug set ospid 93773
SQL>oradebug event 10046 trace name context forever ,level 12
SQL>oradebug tracefile_name
SQL>oradebug close_trace
3、操作系统跟踪
strace -o /tmp/93773 -p 93773
tail -f /tmp/93773
经过跟踪，发现进程无任何信息打印，故认为该进程已经异常，且通过v$sql无法查到产生阻塞的语句，最后联系负责该应用的工程师，重启应用后，该阻塞被释放。 如果重启依然未被释放，则在数据库层面杀掉该会话。
备注：
当应用端认为没有未提交的会话，且数据库端查找不到指定的语句，可以创建新的profiles，并设置IDLE_TIME的值为15-30（分钟），设置resource_limit=true，自动断开inactive的会话，配合sqlnet.ora中的SQLNET.EXPIRE_TIME=10 （分钟）防止未提交的空闲会话阻塞数据库的其他会话。