Oracle DBA日常维护的SQL脚本(常用SQL)

0    835    3

Tags:

👉 本文共约6708个字,系统预计阅读时间或需26分钟。

目录

查看PSU

根据文件号和块号查询数据库对象

元数据获取(表空间、用户、权限)

查询表的历史统计信息

查询索引的历史统计信息

表上列的使用情况

查询字符集

生成AWR

AWR的SQL部分

AWR信息

AWR主机信息

查询碎片程度高的表

条件为什么block>100,因为一些很小的表,只有几行数据实际大小很小,但是block一次性分配就是5个(11g开始默认一次性分配1M的block大小了,见create table storged的NEXT参数),5个block相对于几行小表数据来说就相差太大了。

算法中/0.9是因为块的pfree一般为10%,所以一个块最多只用了90%,而且一行数据大于8KB时容易产生行链接,把一行分片存储,一样的一个块连90%都用不满、

AVG_ROW_LEN还是比较准的,比如个人实验情况一表6个字段,一个number,其他5个都是char(100)但是实际数据都是’1111111’7位,AVG_ROW_LEN显示依然为513

查询索引碎片的比例

集群因子clustering_factor高的表

集群因子越接近块数越好,接近行数则说明索引列的列值相等的行分布极度散列,可能不走索引扫描而走全表扫描

根据sid查spid或根据spid查sid

根据sid查看具体的sql语句

根据spid查询具体的sql语句

查看历史session_id的SQL来自哪个IP

(当然这是个误解,都是历史的了,怎么可能还查到spid,其实查看trace文件名就可以知道spid,trace文件里面有sid和具体sql,如果trace存在incident,那trace就看不到具体sql,但是可以在incident文件中看到具体的sql,如DW_ora_17751.trc中17751就是spid,里面有这样的内容Incident 115 created, dump file: /XX/incident/incdir_115/DW_ora_17751_i115.trc,那么在DW_ora_17751_i115.trc就可以看到具体的sql语句)

DB_ora_29349.trc中出现如下

*** SESSION ID:(5057.12807) 2016-10-26 14:45:52.726

通过表V$ACTIVE_SESSION_HISTORY来查,如下

查询上面的machine的IP是多少

通过上面的spid在oracle服务器上执行netstat -anp |grep spid即可

出现两个,说明来自220,连接了228数据库服务器,但是又通过228服务器的dblink去连接了16服务器

查询DML死锁会话sid,及引起死锁的堵塞者会话blocking_session

BLOCKING_SESSION:Session identifier of the blocking session. This column is valid only if BLOCKING_SESSION_STATUS has the value VALID.

可以在v$session.LOGON_TIME上看到引起死锁的堵塞者会话比等待者要早

如果遇到RAC环境,一定要用gv$来查,并且执行alter system kill session 'sid,serial#'要到RAC对应的实例上去执行

或如下也可以

查询DDL锁的sql

结果为671 0 3 2011-11-1 12:00:00

525 2 0 2011-11-4 12:00:00

查询锁住的DDL对象

查询当前正在执行的sql

查询正在执行的SCHEDULER_JOB

查询正在执行的dbms_job

查询一个会话session、process平均消耗多少内存,查看下面avg_used_M值

TOP 10 执行次数排序

TOP 10 物理读排序

(不要使用DISK_READS/ EXECUTIONS来排序,因为任何一条语句不管执行几次都会耗逻辑读和cpu,可能不会耗物理读(遇到LRU还会耗物理读,LRU规则是执行最不频繁的且最后一次执行时间距离现在最久远的就会被交互出buffer cache),是因为buffer cache存放的是数据块,去数据块里找行一定会消耗cpu和逻辑读的。Shared pool执行存放sql的解析结果,sql执行的时候只是去share pool中找hash value,如果有匹配的就是软解析。所以物理读逻辑读是在buffer cache中,软解析硬解析是在shared pool)

TOP 10 逻辑读排序

(不要使用BUFFER_GETS/ EXECUTIONS来排序,原因同16)

TOP 10 CPU排序

(不要使用CPU_TIME/ EXECUTIONS来排序,原因同16)

查询等待事件

查询当前正在消耗temp空间的sql语句

查询需要使用绑定变量的sql,10G以后推荐第二种

(任何一条执行过的语句不管执行了几次在V$SQL中都只有一条记录,V$SQL中会记录执行了几次。两条一模一样的语句但是在不同的schema下执行的两种结果,如select from t1.test在sye、system下执行则V$SQL只有一条记录(谁先执行则PARSING_SCHEMA_NAME显示谁)。如在sys和system都执行select from test则V$SQL中有两条记录,两条记录的CHILD_NUMBER和PARSING_SCHEMA_NAME不一样。同一个用户下执行一样的语句如果大小写不一样或加了hint的话则会出现多个V$SQL记录,说明V$SQL对应的sql语句必须一模一样,如果alter system flush shared_pool(主站慎用)后再执行一样的语句,发现语句在V$SQL中的SQL_ID和HASH_VALUE与之前的一样,说明SQL_ID和HASH_VALUE应该是oracle自己的一套算法来的,只是根据sql语句内容来进行转换,sql语句不变则SQL_ID和HASH_VALUE也不变。)

第一种

第二种

count(1)>10表示类语句运行了10次以上

查看数据文件可用百分比

查看数据文件可用百分比

查看表空间可用百分比

查看临时表空间使用率

查询undo表空间使用情况

查看ASM磁盘组使用率

统计每个用户使用表空间率

查看闪回区\快速恢复区空间使用率

查看僵死进程,分两种

alter system kill session一执行则session即标记为KILLED,但是如果会话产生的数据量大则这个kill可能会比较久,在这个过程中session标记为KILLED但是这个会话还在V$session中,则V$session.paddr还在,所以可以匹配到V$process.addr,所以process进程还在;当kill过程执行完毕,则这个会话即不在V$session中

会话不在的

会话还在的,但是会话标记为killed

再根据上述结果中的SPID通过如下命令可以查看到process的启动时间

查看行迁移或行链接的表

chain_cnt :Number of rows in the table that are chained from one data block to another or that have migrated to a new block, requiring a link to preserve the old rowid. This column is updated only after you analyze the table.

数据缓冲区命中率

共享池命中率

以下两者应该都可以,看个人怎么理解

查询归档日志切换频率

查询lgwr进程写日志时每执行一次lgwr需要多少秒

在state是waiting的情况下,某个等待编号seq#下,seconds_in_wait达多少秒,就是lgwr进程写一次IO需要多少秒

查询没有索引的表

查询7天的db time

查询产生热块较多的对象

x$bh .tch(Touch)表示访问次数越高,热点快竞争问题就存在

导出AWR报告的SQL语句

查询某个SQL的执行计划

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信dbaup66,谢谢!
AiDBA后续精彩内容已被站长无情隐藏,请输入验证码解锁本文!
验证码:
获取验证码: 请先关注本站微信公众号,然后回复“验证码”,获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复