logo设计在线生成免费网站,建筑行业征信查询平台,微信管理系统官网,华强北 网站建设1. 检查服务器状态
1.1. CPU使用情况
1.1.1. top
top 命令是 Linux 和 Unix 系统中用于显示实时系统状态的工具#xff0c;特别是对于监控 CPU 和内存的使用非常有用。
在命令行中输入 top#xff0c;top 会显示一个实时更新的界面#xff0c;其中包含系统的关键指标特别是对于监控 CPU 和内存的使用非常有用。
在命令行中输入 toptop 会显示一个实时更新的界面其中包含系统的关键指标如 CPU 使用率、内存使用、正在运行的进程等。 界面解读
top 界面通常分为两部分顶部是系统摘要信息底部是当前运行进程的列表。
顶部区域
任务队列load average显示了过去 1 分钟、5 分钟和 15 分钟的平均活动进程数。
CPU 状态
展示了用户us、系统sy、空闲id和等待wa等 CPU 使用情况的百分比。
底部区域
列出了系统中当前活动的进程包括进程 ID、用户、优先级、内存使用情况等。
监控 CPU 使用情况
使用 top 监控 CPU 使用情况时可以关注以下几点
查看 CPU 总体使用率观察顶部区域中的 CPU 状态特别是 %us用户空间使用率和 %sy系统空间使用率。
识别高 CPU 使用的进程在进程列表中top 默认按 CPU 使用率排序。查看列表顶部的进程它们是当前使用 CPU 最多的进程。
注意 PID进程ID、USER运行进程的用户和 %CPU进程使用的 CPU 百分比。
交互式命令
P 可以根据 CPU 使用率对进程进行排序通常这是默认设置。
M 可以根据内存使用率排序。
h 显示帮助菜单。
q 退出 top。
高级用法
实时更新频率启动 top 时可以设置更新频率例如 top -d 2 每 2 秒更新一次。
监控特定用户的进程使用 -u 选项例如 top -u username。
批处理模式top -b 可以在批处理模式下运行 top适用于记录日志或其他非交互式任务。
1.1.2. vmstat
vmstatVirtual Memory Statistics是一个监控系统资源如进程、内存、分页、块 IO、陷阱和 CPU 活动的工具。这个命令可以帮助理解系统的内存压力和 CPU 使用情况。
命令用法 vmstat [间隔] [次数] vmstat 1 10 **将每隔1秒收集系统状态总共收集10次。 CPU 字段分析
us (user): CPU 在用户模式下的时间百分比不包括低优先级进程的时间。
sy (system): CPU 在系统内核模式下的时间百分比。
id (idle): CPU 处于空闲状态的时间百分比。
wa (IO wait): CPU 等待 IO 完成的时间百分比。
st (stolen time): 在虚拟化环境中被虚拟机监视器占用的 CPU 时间百分比。
具体数值分析
用户时间 (us): CPU 在用户模式下的使用率在 8% 到 16% 之间变动这表明 CPU 正在处理用户级的应用程序。
系统时间 (sy): 在大多数时间里系统模式下的 CPU 使用率较低1% 到 4%表示系统负载相对较轻。
空闲时间 (id): CPU 的空闲时间相对较高大多数时间都在 80% 到 89% 之间说明有大量的 CPU 资源未被使用。
IO 等待 (wa): IO 等待时间在大多数情况下都是 1%有一次达到了 4%。这表示 IO 等待对 CPU 性能的影响不大。
被窃取时间 (st): 在输出这段时间中这个值始终为 0%表明没有虚拟化性能损失。
1.1.3. mpstat
mpstat 该命令可以显示单个或多个处理器的统计信息包括每个 CPU 的使用率、系统的平均 CPU 使用率等。
命令用法 mpstat [间隔] [次数] mpstat 1 10 **将每隔1秒收集一次 CPU 使用信息总共收集10次。 字段解析
%usr (%usr): 用户态下 CPU 的使用百分比。
%nice (%nice): 以低优先级运行进程的 CPU 使用百分比。
%sys (%sys): 系统态下内核CPU 的使用百分比。
%iowait (%iowait): 因为 I/O 操作等待而空闲的 CPU 百分比。
%irq (%irq): 为处理硬件中断而使用的 CPU 百分比。
%soft (%soft): 为处理软件中断而使用的 CPU 百分比。
%steal (%steal): 在虚拟环境中其他虚拟机占用的 CPU 时间百分比。
%guest (%guest): 运行虚拟处理器的时间百分比。
%gnice (%gnice): 运行具有低优先级的虚拟处理器的时间百分比。
%idle (%idle): CPU 处于空闲状态的时间百分比。
具体数值分析
CPU 用户时间 (%usr): 范围在 2.14% 到 8.48% 之间表明 CPU 正在处理用户级的应用程序但负载不高。
CPU 系统时间 (%sys): 范围在 1.01% 到 2.40% 之间这是正常的系统运行范围。
CPU I/O 等待时间 (%iowait): 有波动最高达到 6.46%表明有些时刻 CPU 在等待 I/O 操作但总体来说并不频繁。
CPU 空闲时间 (%idle): 大部分时间都在 90% 左右说明 CPU 大部分时间都处于空闲状态有足够的处理能力。 1.2. 内存使用情况
1.2.1. free
free 命令在 Linux 中用于显示系统中空闲和已使用的内存量。提供有关物理内存、交换内存和内核使用的缓冲区的信息。
命令用法 free -b以byte为单位显示输出。 -k以kb为单位显示输出。这是默认单位。 -m以mb为单位显示输出。 -g以gb节为单位显示输出。 -t显示一行包括 RAM 和交换内存的总和。 -h以合适的单位显示内存使用情况最大为三位数自动计算对应的单位值。自动将输出规模化到最短的三位单位。 -s 秒每隔 秒 秒更新一次输出。 字段解析
total: 表示总的物理内存大小。
used: 表示已经被使用的内存量。
free: 表示当前未被使用的内存量。
shared: 表示多个进程共享的内存量。
buff/cache: 表示被系统用作缓冲和缓存的内存量。
available: 表示估算的对应用程序可用的内存量考虑了缓存和不可回收的内存。
Swap: 交换空间的使用情况。
total: 交换空间的总量。
used: 已经被使用的交换空间量。
free: 当前未被使用的交换空间量。
具体数值分析
Mem:
总内存 (total)15GB这是服务器的全部物理内存。
已用内存 (used)15GB几乎所有的物理内存都在使用中。
空闲内存 (free)149MB非常少的内存量是空闲的。
共享内存 (shared)23MB这是被多个进程共享的内存。
缓冲/缓存 (buff/cache)407MB系统用于缓冲和缓存的内存量。
可用内存 (available)187MB尽管大部分内存都在使用中但是还有一些内存可以被新的应用程序使用不过这个量也相对较少。
Swap:
总交换 (total)8.0GB这是系统配置的总交换空间。
已用交换 (used)1.8GB已经使用了一部分交换空间。
空闲交换 (free)6.2GB大部分交换空间还是空闲的。
1.2.2. vmstat
vmstatVirtual Memory Statistics是一个监控系统资源如进程、内存、分页、块 IO、陷阱和 CPU 活动的工具。这个命令可以帮助理解系统的内存压力和 CPU 使用情况。
命令用法 vmstat [间隔] [次数] vmstat 1 10 将每隔1秒收集系统状态总共收集10次。 内存字段解析
swpd: 使用的交换空间大小单位KB。
free: 空闲的物理内存大小单位KB。
buff: 用作缓冲区的内存大小单位KB。
cache: 用作页面缓存的内存大小单位KB。
具体数值解析
swpd 字段值为 1945884 KB表示有约 1.9 GB 的内存内容被换出到交换空间。
free 字段空闲内存相对较少介于 177820 KB 到 196020 KB 之间系统可用的空闲内存不多。
cache 字段缓存内存变化不大约为 424536 KB 到 433728 KB操作系统用于缓存的内存保持相对稳定。 1.3. 磁盘使用情况
1.3.1. 文件系统使用情况
dfdisk filesystem命令在 Linux 中用于显示文件系统的磁盘空间使用情况。它会报告文件系统的总空间、已使用空间、可用空间以及挂载点信息
命令用法 df [选项] -h: 以合适的格式显示信息例如自动选择 KB、MB 或 GB。 -T: 显示每个文件系统的类型。 -a: 显示所有文件系统的信息包括通常不显示的系统文件系统。 --total: 显示总计行。 -i: 显示 inode 信息而不是块使用情况。 字段解析
Filesystem列出了检测到的每个文件系统或分区。
Size文件系统的总空间大小。
Used文件系统上已使用的空间量。
Avail文件系统上可用的空间量。
Use%文件系统已使用空间的百分比。
Mounted on文件系统挂载的目录。
1.3.2. 磁盘 IO 情况
iostat命令 用于监视系统输入输出设备和CPU的使用情况。它的特点是汇报磁盘活动统计情况同时也会汇报出CPU使用情况。
命令用法 iostat[选项] -c仅显示 CPU 使用率。 -d仅显示磁盘 I/O 统计。 -x显示扩展的磁盘 I/O 统计。 -t显示时间戳信息。 -k以千字节为单位显示。 -m以兆字节为单位显示。 -p [设备]显示指定设备或分区的统计数据。 字段解析
Device:监测设备名称
rrqm/s: 每秒合并到设备队列的读请求数。
wrqm/s: 每秒合并到设备队列的写请求数。
r/s: 每秒完成的读 I/O 操作数。
w/s: 每秒完成的写 I/O 操作数。
rMB/s: 每秒从设备读取的数据量以 MB 为单位。
wMB/s: 每秒向设备写入的数据量以 MB 为单位。
avgrq-sz: 平均每次 I/O 操作的大小以扇区为单位。
avgqu-sz: 平均 I/O 队列长度。
await: 平均 I/O 请求的等待时间以毫秒为单位。
r_await: 读请求的平均等待时间。
w_await: 写请求的平均等待时间。
svctm: 平均服务时间不再推荐使用因为这个值可能不准确。
%util: 设备的带宽利用率百分比。接近 100% 表示设备可能成为性能瓶颈。
2. 检查网络状态
网络延迟和带宽确保网络稳定无异常延迟或拥塞。
2.1. ping
使用 ping 命令检查节点之间的网络延迟。例如从一个节点 ping 另一个节点并观察响应时间。
命令用法 ping [选项][目标主机] 选项
-d使用Socket的SO_DEBUG功能
-c完成次数设置完成要求回应的次数
-f极限检测
-i间隔秒数指定收发信息的间隔时间
-I网络界面使用指定的网络界面送出数据包
-l前置载入设置在送出要求信息之前先行发出的数据包
-n只输出数值
-p范本样式设置填满数据包的范本样式
-q不显示指令执行过程开头和结尾的相关信息除外
-r忽略普通的Routing Table直接将数据包送到远端主机上
-R记录路由过程
-s数据包大小设置数据包的大小
-t存活数值设置存活数值TTL的大小
-v详细显示指令的执行过程。
-w超时秒数无论之前发送或接受了多少包只要超过此秒数程序退出 示例 源端地址rac1(192.168.1.61)
目标地址rac2(192.168.1.62)
发送的数据包数量共发送了 2 个 ICMP 数据包。
接收的数据包数量成功接收了 2 个回复表示两个数据包都成功到达目标并返回。
数据包丢失率丢包率为 0%表示在测试期间没有数据包丢失。
往返时间RTT
第一个数据包的 RTT0.210 毫秒
第二个数据包的 RTT0.226 毫秒
统计数据
最短 RTT0.210 毫秒
平均 RTT0.218 毫秒
最长 RTT0.226 毫秒
RTT 波动mdev0.008 毫秒
2.2. traceroute
traceroute可以帮助识别数据包在网络中的路径和每个跳点的延迟。
命令用法 traceroute [选项][目标主机] -d使用Socket层级的排错功能
-f存活数值设置第一个检测数据包的存活数值TTL的大小
-F设置勿离断位
-g网关设置来源路由网关最多可设置8个
-i网络界面使用指定的网络界面送出数据包
-I使用ICMP回应取代UDP资料信息
-m存活数值设置检测数据包的最大存活数值TTL的大小
-n直接使用IP地址而非主机名称
-p通信端口设置UDP传输协议的通信端口
-r忽略普通的Routing Table直接将数据包送到远端主机上。
-s来源地址设置本地主机送出数据包的IP地址
-t服务类型设置检测数据包的TOS数值
-v详细显示指令的执行过程
-w超时秒数设置等待远端主机回报的时间
-x开启或关闭数据包的正确性检验。 示例 源端地址rac61(192.168.1.61)
目标地址rac62(192.168.1.62)
结果只有一个跳点显示为 rac62 (192.168.1.62)。
延迟时间
第一次测量0.247 毫秒
第二次测量0.266 毫秒
第三次测量0.249 毫秒
3. 检查集群状态
3.1. 节点健康状况
在 Oracle Real Application Clusters (RAC) 环境中可以使用 Oracle Clusterware 工具来检查集群状态。这些工具提供了关于集群资源和节点状态的详细信息帮助数据库管理员监控和管理集群环境。
3.1.1. crsctl命令
crsctl 是 Oracle Clusterware 的一个命令行工具用于管理集群资源和检查集群状态。常用的 crsctl 命令包括
检查集群服务状态: crsctl status resource -t 在 Oracle Real Application Clusters (RAC) 中ora.gsdGlobal Services Daemon是一个在 Oracle 10g RAC 和更早版本中用于支持服务管理功能的进程。从 Oracle 11g 开始这个功能已被 Oracle Clusterware 的 ora.crsdCluster Ready Services Daemon接管。
在 Oracle 11g 和更高版本中ora.gsd 服务通常保持 OFFLINE 状态因为它不再需要在新的集群管理架构中提供服务。因此如果正在运行 Oracle 11g 或更高版本的 RAC并且看到 ora.gsd 服务处于 OFFLINE 状态这是正常现象不会影响 RAC 的功能和性能。
检查集群中所有节点的状态: crsctl check cluster -all CRS-4537: 表明 Cluster Ready ServicesCRS是在线的。CRS 是 Oracle 集群的一个重要组成部分负责管理和监控集群中的资源。
CRS-4529: 显示 Cluster Synchronization ServicesCSS也是在线的。CSS 负责在集群节点之间维护成员资格信息和节点间同步。
CRS-4533: 指出 Event Manager 也是在线的。它负责处理集群事件和响应。
检查集群同步服务守护进程的状态: crsctl check css CRS-4529:Cluster Synchronization Services is online 表明集群同步服务目前处于在线状态。 3.2. 集群互连检查
3.2.1. 使用 Clusterware 工具
3.2.1.1. crsctl 命令
检查集群服务状态 crsctl status resource -t 查看特定资源的状态比如网络接口 crsctl status resource ora.net1.network 3.2.1.2. oifcfg 命令
查看集群网络配置 ifcfg getif 这将显示所有配置的网络接口包括用于互连的专用网络。
3.2.2. Oracle 集群日志
检查 Oracle Grid Infrastructure 的日志特别是针对集群互连的部分以识别任何网络相关的错误或警告。
日志路径$GRID_HOME/log/[节点名]/alert[节点名].log 例:$GRID_HOME/log/rac1/alertrac1.log 搜索关键字
搜索错误消息或警告如 ORA- 开头的错误代码。 tail -n 1000 /oracle/app/11.2.0/grid/log/rac1/alertrac1.log | grep ORA- 寻找与网络相关的关键字如 network, interface, timeout, connection 等。 grep -E network|interface|timeout|connection /oracle/app/11.2.0/grid/log/rac1/alertrac1.log 3.2.3. 网络检查
使用 ping、traceroute 等命令测试节点间的网络连通性。【参考2.检查网络状态】
使用 netstat 或 ss 命令来查看网络端口和连接状态。
命令格式 ss -an | grep [端口号] 示例 ss -an | grep 1521 3.3. 查看 Oracle 集群日志
检查 Oracle Grid Infrastructure 的日志文件特别是针对集群互连的部分如 crsd.log、cssd.log 等。
命令格式 grep 关键字 $GRID_HOME/log/[节点名]/crs/crsd.log grep ORA- $GRID_HOME/log/[节点名]/cssd/cssd.log 3.4. 集群软件打补丁和更新状态
确保所有节点上的 Oracle 软件和操作系统补丁都是最新的。
3.4.1. OPatch 工具 $ORACLE_HOME/OPatch/opatch lspatches 3.4.2. SQL 查询
DBA_REGISTRY_HISTORY 视图提供了关于数据库补丁和更新历史的信息
select * from dba_registry_history; 4. 检查Oracle实例
4.1. 实例状态
确保所有实例都处于打开状态。
4.1.1. 使用 SQL*Plus
连接到每个实例并执行以查看实例的状态。状态应为 OPEN。
SELECT INSTANCE_NAME, STATUS FROM V$INSTANCE; 对于 RAC还可以检查 GV$INSTANCE 视图以在所有节点上查看实例的状态。
SELECT INSTANCE_NAME, STATUS FROM GV$INSTANCE; 4.1.2. 使用 Oracle RAC 管理工具
查询数据库中所有实例的状态。
srvctl status database -d [数据库名] 查看集群中各种资源包括数据库实例的状态。 crsctl status resource -t 4.2. SGA和PGA使用情况
监控共享内存和进程内存的使用。 4.2.1. SGA 使用情况
查看 SGA 的大小和使用情况。
SELECT * FROM V$SGA; 在 SQL*Plus 中快速查看 SGA 统计信息。 SHOW SGA 字段解析
Total System Global Area: 2,455,228,416 字节表示 SGA 的总大小。
Fixed Size: 2,255,712 字节这部分内存大小是固定的用于存储数据库实例的一些内部结构。
Variable Size: 671,089,824 字节这部分大小可变包括共享池、大池和 Java 池。
Database Buffers: 1,761,607,680 字节用于缓存数据库的数据块。
Redo Buffers: 20,275,200 字节用于缓存重做日志信息。
4.2.2. PGA 使用情况
SELECT
(SELECT value / 1024 / 1024 FROM v$parameter WHERE name pga_aggregate_target) AS PGA_AGGREGATE_TARGET(M),
(SELECT ROUND(SUM(pga_alloc_mem) / 1024 / 1024) FROM v$process) AS alloc_mb,
(SELECT ROUND(SUM(PGA_USED_MEM) / 1024 / 1024) FROM v$process) AS used_mb
FROM dual; PGA_AGGREGATE_TARGET(M)显示 pga_aggregate_target 参数的值即 Oracle 为 PGA 分配的目标内存大小以 MB 为单位。
ALLOC_MB显示当前所有进程分配的 PGA 内存总量以 MB 为单位。pga_alloc_mem 是每个进程分配的 PGA 内存量。
USED_MB显示当前所有进程实际使用的 PGA 内存总量以 MB 为单位。 4.2.3. 查询相关会话信息
select s.sid,
s.serial#,
s.username,
s.event,
s.machine,
s.program,
s.sql_id,
round(p.pga_alloc_mem / 1048576) size_m,
p.spid
from v$session s, v$process p
where s.paddr p.addr
and p.pga_alloc_mem 10485760
order by p.pga_alloc_mem desc; 字段解析
sid:会话 ID。这是用于唯一标识数据库会话的数字。
serial#:会话的序列号。它与 SID 一起用于唯一标识会话。
username:连接到数据库的用户名称。
event:会话当前正在等待的事件这有助于了解会话可能遇到的任何延迟或阻塞。
machine:用户连接到数据库的机器名称。
program:正在运行的程序名称。这可以是用户正在运行的客户端应用程序。
sql_id:当前会话执行的 SQL 语句的唯一标识符。
size_m:分配给该进程的 PGA 内存大小单位为 MB。这是通过将 p.pga_alloc_mem以字节为单位转换为 MB 来计算得出的。
p.spid:操作系统级别的进程 ID。 5. 检查数据库健康状况
5.1. 表空间管理
5.1.1. 常规表空间
5.1.1.1. 常规表空间使用率
set pagesize 9999 line 9999
col LOGGING for a10
col STATUS for a10
col TS_DF_COUNT for 9999
col TS_Name format a25
WITH WT1 AS (SELECTTS.TABLESPACE_NAME,DF.ALL_BYTES,DECODE(DF.TYPE, D, NVL(FS.FREESIZ, 0), T, DF.ALL_BYTES - NVL(FS.FREESIZ, 0)) FREESIZ,FS.NEXT_MAX_EXTENT_MB,DF.MAXSIZ,TS.BLOCK_SIZE,TS.LOGGING,TS.FORCE_LOGGING,TS.CONTENTS,TS.EXTENT_MANAGEMENT,TS.SEGMENT_SPACE_MANAGEMENT,TS.RETENTION,TS.DEF_TAB_COMPRESSION,DF.TS_DF_COUNT,TS.BIGFILE,TS.STATUSFROMDBA_TABLESPACES TS,(SELECTD TYPE,TABLESPACE_NAME,COUNT(*) TS_DF_COUNT,SUM(BYTES) ALL_BYTES,SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES)) MAXSIZFROMDBA_DATA_FILES DGROUP BYTABLESPACE_NAMEUNIONALLSELECTT,TABLESPACE_NAME,COUNT(*) TS_DF_COUNT,SUM(BYTES) ALL_BYTES,SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES))FROMDBA_TEMP_FILES DGROUP BYTABLESPACE_NAME) DF,(SELECTTABLESPACE_NAME,SUM(BYTES) FREESIZ,MAX(BYTES)/1024/1024 NEXT_MAX_EXTENT_MBFROMDBA_FREE_SPACEGROUP BYTABLESPACE_NAMEUNIONALLSELECTTABLESPACE_NAME,SUM(D.BLOCK_SIZE * A.BLOCKS) BYTES,NULLFROMGV$SORT_USAGE A,DBA_TABLESPACES DWHEREA.TABLESPACE D.TABLESPACE_NAMEGROUP BYTABLESPACE_NAME) FSWHERETS.TABLESPACE_NAME DF.TABLESPACE_NAMEAND TS.TABLESPACE_NAME FS.TABLESPACE_NAME()
)
SELECT(SELECTA.TS#FROMV$TABLESPACE AWHEREA.NAME UPPER(T.TABLESPACE_NAME)) TS#,T.TABLESPACE_NAME TS_NAME,ROUND(T.ALL_BYTES / 1024 / 1024) TS_SIZE_M,ROUND(T.FREESIZ / 1024 / 1024) FREE_SIZE_M,ROUND(T.NEXT_MAX_EXTENT_MB) NEXT_MAX_EXTENT_M,ROUND((T.ALL_BYTES - T.FREESIZ) / 1024 / 1024) USED_SIZE_M,ROUND((T.ALL_BYTES - T.FREESIZ) * 100 / T.ALL_BYTES,3) USED_PER,ROUND(MAXSIZ / 1024 / 1024 / 1024,3) MAX_SIZE_G,ROUND(DECODE(MAXSIZ,0,TO_NUMBER(NULL),(T.ALL_BYTES - FREESIZ)) * 100 / MAXSIZ,3) USED_PER_MAX,ROUND(T.BLOCK_SIZE) BLOCK_SIZE,T.LOGGING,T.BIGFILE,T.STATUS,T.TS_DF_COUNT
FROMWT1 T
UNION
ALL
SELECTTO_NUMBER() TS#,ALL TS: TS_NAME,ROUND(SUM(T.ALL_BYTES) / 1024 / 1024, 3) TS_SIZE_M,ROUND(SUM(T.FREESIZ) / 1024 / 1024) FREE_SIZE_M,ROUND(SUM(T.NEXT_MAX_EXTENT_MB)) NEXT_MAX_EXTENT_M,ROUND(SUM(T.ALL_BYTES - T.FREESIZ) / 1024 / 1024) USED_SIZE_M,ROUND(SUM(T.ALL_BYTES - T.FREESIZ) * 100 / SUM(T.ALL_BYTES), 3) USED_PER,ROUND(SUM(MAXSIZ) / 1024 / 1024 / 1024) MAX_SIZE,TO_NUMBER() USED,% of MAX Size,TO_NUMBER() BLOCK_SIZE, LOGGING,MAX(T.BIGFILE),MAX(T.STATUS),TO_NUMBER() TS_DF_COUNT
FROMWT1 T
ORDER BYUSED_PER_MAX;字段解析
TS#:表空间的编号。这是从 V$TABLESPACE 视图中获取的表空间的内部标识符。
TS_NAME:表空间名称。表示表空间的名称。
TS_SIZE_M:表空间总大小以 MB 为单位。这是表空间的总容量。
FREE_SIZE_M:表空间的空闲空间以 MB 为单位。表示当前未被使用的空间量。
NEXT_MAX_EXTENT_M:下一个最大扩展的大小以 MB 为单位。表示下一个分配的扩展区可能达到的最大大小。
USED_SIZE_M:表空间中已使用的空间量以 MB 为单位。计算方式为总大小减去空闲大小。
USED_PER:表空间的使用百分比。表示已使用空间占总空间的百分比。
MAX_SIZE_G:表空间的最大可能大小以 GB 为单位。这通常是基于数据文件的最大大小设置。
USED_PER_MAX:相对于最大大小的使用百分比。这是已使用空间占最大可能大小的百分比。
BLOCK_SIZE:数据块大小。表示表空间中数据块的大小。
LOGGING:日志记录方式。指示表空间是否启用了日志记录。
BIGFILE:是否为大文件表空间。大文件表空间支持单个非常大的数据文件。
STATUS:表空间的状态。例如ONLINE、OFFLINE。
TS_DF_COUNT:表空间数据文件的数量。表示该表空间中数据文件的总数。
5.1.1.2. 查询表空间数据文件信息
SELECT SUBSTR(max(A.TABLESPACE_NAME),1,20) Tablespace,A.FILE_ID FILE_ID,substr(max(A.file_name),1,60) Data file,substr(max(A.status),1,10) Status,A.online_status ONLINE_STATUS,TO_CHAR(d.creation_time, yyyy-mm-dd hh24:mi) creation_time,A.Autoextensible AUTOEXTENSIBLE,(MAX(A.BYTES)-nvl(sum(B.BYTES),0))/1024/1024 USED_M,nvl(sum(B.BYTES),0)/1024/1024 FREE_M,MAX(A.bytes)/1024/1024 TOTAL_M,TO_CHAR((MAX(A.BYTES)-nvl(sum(B.BYTES),0))*100/MAX(A.BYTES),999.99)||% USED%,A.MAXBYTES/1024/1024/1024 Max_Extend_Gfrom dba_data_files A,DBA_FREE_SPACE B,v$DATAFILE dWHERE A.FILE_IDB.FILE_ID() and A.FILE_IDd.FILE#group by a.file_id,A.online_status,d.creation_time,A.AUTOEXTENSIBLE,A.MAXBYTES/1024/1024/1024order by 1,6; 5.1.2. 临时表空间
5.1.2.1. 检查临时表空间使用率
SELECTD.TABLESPACE_NAME Tablespace_name,D.CONTENTS Type,D.EXTENT_MANAGEMENT Extent,TO_CHAR(NVL(A.BYTES / 1024 / 1024, 0), 99,999,990.99) Size (M),TO_CHAR(NVL(T.BYTES_CACHED, 0)/1024/1024, 99,999,999.99) CACHED (M),TO_CHAR(NVL(T.BYTES_USED/1024/1024, 0), 99,999,999.99) Using (M),TO_CHAR(NVL(T.BYTES_CACHED / A.BYTES * 100, 0), 990.00) CACHED %,TO_CHAR(NVL(T.BYTES_USED / A.BYTES * 100, 0), 990.00) Using %
FROMSYS.DBA_TABLESPACES D,(SELECTTABLESPACE_NAME,SUM(BYTES) BYTESFROMDBA_TEMP_FILESGROUP BYTABLESPACE_NAME) A,(SELECTTABLESPACE_NAME,SUM(BYTES_CACHED) BYTES_CACHED,SUM(BYTES_USED) BYTES_USEDFROMGV$TEMP_EXTENT_POOLGROUP BYTABLESPACE_NAME) T
WHERED.TABLESPACE_NAME A.TABLESPACE_NAME()AND D.TABLESPACE_NAME T.TABLESPACE_NAME()AND D.EXTENT_MANAGEMENT LIKE LOCALAND D.CONTENTS LIKE TEMPORARY; 字段解析:
Tablespace_name表空间名称。
Type表空间的内容类型TEMPORARY 表示临时。
Extent扩展管理方式LOCAL 表示本地管理。
Size (M)表空间的总大小以 MB 为单位。
CACHED (M)表空间中缓存的数据量以 MB 为单位。
Using (M)表空间中正在使用的数据量以 MB 为单位。
CACHED %缓存数据量占表空间总大小的百分比。
Using %正在使用的数据量占表空间总大小的百分比。 5.1.2.2. 查询临时表空间文件信息
select c.name Tablespace_name,
b.file#,
b.name tempfile,
b.CREATION_TIME,
b.STATUS,
b.ENABLED,
round(b.BYTES / 1024 / 1024) sum_mb
from v$tempfile b, v$tablespace c
where b.ts# c.ts#
order by b.CREATION_TIME; 字段解析:
Tablespace_name: 临时文件所属的表空间名称。
file#: 临时文件的编号。
tempfile: 临时文件的名称。
CREATION_TIME: 临时文件的创建时间。
STATUS: 临时文件的状态。
ENABLED: 表示临时文件是否启用。
sum_mb: 临时文件的大小以 MB 为单位。 5.1.2.3. 查询临时表空间相关事务信息 select c.name Tablespace_name,
b.file#,
b.name tempfile,
b.CREATION_TIME,
b.STATUS,
b.ENABLED,
round(b.BYTES / 1024 / 1024) sum_mb
from v$tempfile b, v$tablespace c
where b.ts# c.ts#
order by b.CREATION_TIME;select b.inst_id,
b.SID,
b.SERIAL#,
b.username,
b.status,
b.event,
b.sql_id,
b.prev_sql_id,
b.machine,
a.SEGFILE#,
sum(a.blocks) * (select to_number(VALUE) from v$parameter where NAME db_block_size) / 1024 / 1024 MB,
a.TABLESPACEfrom gv$TEMPSEG_USAGE a, gv$SESSION b
where a.inst_idb.inst_id and a.SESSION_ADDR b.SADDR
group by b.inst_id,b.username,b.SID,b.SERIAL#,b.status,b.event,b.sql_id, b.prev_sql_id,b.machine,a.SEGFILE#,a.TABLESPACE
order by b.inst_id, MB desc; 字段解析:
各种会话信息inst_id, SID,SERIAL#,username,status,event, sql_id, prev_sql_id, machine: 提供了会话的详细信息包括会话 ID、用户、状态、事件、执行的 SQL ID 等。
SEGFILE#: 使用的临时文件编号。
MB: 会话使用的临时段大小以 MB 为单位计算基于 db_block_size 初始化参数。
TABLESPACE: 使用的临时表空间。
5.1.3. UNDO表空间
5.1.3.1. 查询UNDO信息
select name, value from v$parameter where name in (undo_management,undo_retention,undo_tablespace); 字段解析:
undo_management: 此参数确定 UNDO 数据的管理方式。在 Oracle 数据库中它通常设置为 AUTO表示 UNDO 管理是自动的由数据库自身处理。
undo_retention: 指定了 UNDO 数据的保留时间以秒为单位。这是数据库在需要回滚或提供一致性读取时保留 UNDO 数据的最小时间。设置此参数有助于在数据库中管理可用的 UNDO 空间。
undo_tablespace: 指定了用作默认 UNDO 表空间的表空间的名称。当事务需要 UNDO 空间时它将使用此表空间。
5.1.3.2. 查询UNDO表空间使用率
SELECT d.tablespace_name ,
TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),99,999,999.99) SIZE (M),
TO_CHAR((a.bytes-f.bytes)/1024/1024,99,999,999.99) Used_HWM (M),
TO_CHAR(NVL((a.bytes-f.bytes)/a.bytes* 100, 0),99,999,999.99) Used_HWM %,
TO_CHAR(NVL(u.bytes, 0) / 1024 / 1024,99,999,999.99) Using (M),
TO_CHAR(NVL(u.bytes / a.bytes * 100, 0), 990.00) Using %,
a.autoext Autoextend,
TO_CHAR(NVL(a.bytes - NVL(u.bytes, 0), 0) / 1024 / 1024,99,999,999.99) Free (M),
d.status,
a.count # of datafiles,
d.contents TS type,
d.extent_management EXT MGMT,
d.segment_space_management Seg Space MGMTFROM sys.dba_tablespaces d,
(SELECT tablespace_name,SUM(bytes) bytes,COUNT(file_id) count, decode(sum(decode(autoextensible, NO, 0, 1)),0,NO,YES) autoext FROM dba_data_files GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes) bytesFROM (SELECT tablespace_name, sum(bytes) bytes, status from dba_undo_extents WHERE status ACTIVE group by tablespace_name, statusUNION ALLSELECT tablespace_name, sum(bytes) bytes, status from dba_undo_extents WHERE status UNEXPIRED group by tablespace_name, status)group by tablespace_name) u,(select tablespace_name, sum(bytes) bytes from dba_free_space group by tablespace_name) f
WHERE d.tablespace_name a.tablespace_name()
AND d.tablespace_name u.tablespace_name()
AND d.tablespace_name f.tablespace_name()
AND d.contents UNDO; 字段解析:
tablespace_name表空间名称。
SIZE (M)表空间的总大小以 MB 为单位。
Used_HWM (M)表空间的高水位使用量以 MB 为单位。
Used_HWM %高水位使用量占总大小的百分比。
Using (M)当前正在使用的空间量以 MB 为单位。
Using %正在使用的空间占总空间的百分比。
Autoextend表明表空间的数据文件是否设置为自动扩展。
Free (M)表空间中的空闲空间以 MB 为单位。
status表空间的状态例如ONLINE、OFFLINE。
# of datafiles表空间中数据文件的数量。
TS type表空间类型这里特别指 UNDO。
EXT MGMT表空间的扩展管理方式。
Seg Space MGMT表空间的段空间管理策略。
5.1.3.3. 查询UNDO使用情况
select a.tablespace_name,
a.status,
to_char(a.use_mb,99,999,999.99) Used (M),
to_char(a.use_mb / b.total_mb * 100,99,999,999.99) Using %from (select owner,
tablespace_name,
status,
sum(bytes) / 1024 / 1024 use_mbfrom dba_undo_extents
group by owner, tablespace_name, status) a,
(select tablespace_name, sum(bytes) / 1024 / 1024 total_mbfrom dba_data_files
where tablespace_name like %UNDO%
group by tablespace_name) b
where a.tablespace_name b.tablespace_name
order by 1, 2, 3; 字段解析:
ACTIVE表示扩展目前正在被事务使用。
EXPIRED表示扩展不再被事务使用且可以被重用。
UNEXPIRED表示扩展不再被事务使用但还没有达到自动重用的条件。
5.1.3.4. 查询UNDO相关的事务信息
select s.inst_id,s.sid,
s.username,
s.program,
s.event,
s.sql_id,
r.name RBS name,
t.START_TIME,
t.USED_UBLK undo_blocks,
t.USED_UREC undo_rows,
t.STATUS,
t.LOG_IO,
t.PHY_IOfrom gv$session s, gv$transaction t, v$rollname r
where s.saddr t.SES_ADDR and r.usn t.xidusn and s.inst_idt.inst_id; 5.2. ASM管理
5.2.1. 查询ASM磁盘详细信息
select name,path,GROUP_NUMBER GRP#,DISK_NUMBER DISK#,MODE_STATUS,HEADER_STATUS,TOTAL_MB,FREE_MB,FAILGROUP from v$asm_disk order by 3,9; 字段解析:
name: ASM 磁盘的名称。
path: 磁盘的路径。
GROUP_NUMBER (别名 GRP#): 磁盘所属的磁盘组编号。
DISK_NUMBER (别名 DISK#): 磁盘在其所属磁盘组中的编号。
MODE_STATUS: 磁盘的模式状态例如是否处于在线状态。
HEADER_STATUS: 磁盘头的状态例如是否已被标记为属于某个 ASM 磁盘组。
TOTAL_MB: 磁盘的总容量以 MB 为单位。
FREE_MB: 磁盘上的可用空间以 MB 为单位。
FAILGROUP: 磁盘所属的故障组。
5.2.2. 查询ASM磁盘组使用情况
select GROUP_NUMBER, NAME, TYPE, STATE,TOTAL_MB, FREE_MB,TOTAL_MB-FREE_MB USE_MB, (TOTAL_MB-FREE_MB)/TOTAL_MB USE_PER from v$asm_diskgroup order by USE_PER; 字段解析:
GROUP_NUMBER: 磁盘组编号。
NAME: 磁盘组的名称。
TYPE: 磁盘组的类型。
STATE: 磁盘组的状态。
TOTAL_MB: 磁盘组的总容量以 MB 为单位。
FREE_MB: 磁盘组中的可用空间以 MB 为单位。
USE_MB: 磁盘组中已使用的空间以 MB 为单位。
USE_PER: 磁盘组使用率的百分比。 5.3. 重做日志和归档日志
监控重做日志的生成和归档日志的状态。
5.3.1. 重做日志
5.3.1.1. 查询重做日志组信息
SELECT
i.instance_name
, i.thread#
, f.group#
, f.member
, f.type
, l.status
, l.bytes/1048576 mb
, l.archived
FROM
gv$logfile f
, gv$log l
, gv$instance i
WHERE
f.group# l.group#
AND l.thread# i.thread#
AND i.inst_id f.inst_id
AND f.inst_id l.inst_id
ORDER BY
i.instance_name
, f.group#
, f.member
/ 字段解析
INSTANCE_NAME: Oracle RAC 实例的名称。
THREAD#: 重做日志线程编号通常每个 RAC 实例对应一个线程。
GROUP#: 重做日志组的编号一组可以包含一个或多个重做日志文件。
MEMBER: 重做日志文件的路径和文件名。
TYPE: 这显示了文件是归档日志ARCH还是在线日志ONLINE。
STATUS: 显示重做日志文件的状态CURRENT 表示当前正在使用的日志文件而 INACTIVE 表示当前未使用的日志文件。
MB: 重做日志文件的大小以兆字节为单位。
ARC: 表示是否已将该重做日志文件归档YES 表示已归档NO 表示尚未归档
5.3.1.2. 查询重做日志统计信息
select inst_id,to_char(BeginTime,mm/dd/yy hh24:mi) begintime, redo_mb,redo_time,wast_mb,redo_read,log_buffer,log_space,log_space_time,direct_wirte
from (SELECT sn.instance_number inst_id,
cast(sn.begin_interval_time as date) BeginTime,
cast(sn.END_INTERVAL_TIME as date) EndTime,
round(sum(decode(ss.stat_name,
redo size,
ss.curval - ss.prevval,
0)) / 1048576,
2) redo_mb,
round(sum(decode(ss.stat_name,
redo write time,
ss.curval - ss.prevval,
0)) / 100,
2) redo_time,
round(sum(decode(ss.stat_name,
redo wastage,
ss.curval - ss.prevval,
0)) / 1048576,
2) wast_mb,
round(sum(decode(ss.stat_name,
redo KB read,
ss.curval - ss.prevval,
0)) / 1024,
2) redo_read,
round(sum(decode(ss.stat_name,
redo buffer allocation retries,
ss.curval - ss.prevval,
0)) ,
2) log_buffer,
round(sum(decode(ss.stat_name,
redo log space requests,
ss.curval - ss.prevval,
0)) ,
2) log_space ,
round(sum(decode(ss.stat_name,
redo log space wait time,
ss.curval - ss.prevval,
0))/100 ,
2) log_space_time,
round(sum(decode(ss.stat_name,
redo size for direct writes,
ss.curval - ss.prevval,
0)) /1048576,
2) direct_wirte
FROM dba_hist_snapshot sn,
(SELECT snap_id,
stat_name,
instance_number,
dbid,
VALUE curval,
lag(value, 1, to_number(null)) over(partition by stat_id, instance_number order by snap_id) prevval
FROM dba_hist_sysstat
WHERE stat_name in (redo KB read, redo size,redo write time,redo buffer allocation retries,
redo log space requests,redo log space wait time,redo wastage,redo size for direct writes)) ss
WHERE sn.snap_id ss.snap_id
and sn.dbid ss.dbid
and sn.instance_number ss.instance_number
and begin_interval_time trunc(sysdate - 2)
group by sn.instance_number,cast(sn.begin_interval_time as date), cast(sn.END_INTERVAL_TIME as date)
order by 1, 2) s
ORDER BY 1, 2
/ 字段解析:
ID: 实例 ID 或节点 ID。
BeginTime: 统计开始的时间。
Redo Gen (MB): 在指定时间段内生成的重做数据量以兆字节为单位。
Redo Write (sec): 完成重做日志写入所需的总时间以秒为单位。
Redo was (MB): 重做日志的浪费空间量以兆字节为单位。
Redo read (MB): 读取的重做数据量以兆字节为单位。
buffer alloc retry: 重做日志缓冲区分配重试的次数。
space requests: 由于日志空间不足而进行的请求次数。
space time: 等待日志空间分配的时间以秒为单位。
direct write (MB): 直接写入重做日志的数据量以兆字节为单位。
具体数据分析
重做日志生成在统计期间重做日志的生成量变化较大有些时段活跃例如 01/02 09:00 有 6 MB而 01/02 19:00 有 10 MB。
写入时间大多数时间段的写入时间非常短平均在几秒以内这表明日志写入操作相对迅速。
重做日志浪费大部分时间段内没有重做日志空间浪费表示重做日志的使用效率很高。
读取量重做日志读取量整体较低这可能表明对于恢复操作的需求不是很频繁。
缓冲区分配重试几乎没有缓冲区分配重试这表明内存足够用于重做日志操作。
日志空间请求没有日志空间不足的请求表示分配给重做日志的空间充足。
等待日志空间几乎没有因等待空间而产生的时间延迟显示出良好的性能。
直接写入量直接写入重做日志的数据量很小这表明大多数重做日志活动是正常缓冲的。
5.3.2. 归档日志
5.3.2.1. 归档切换频率
查询指定时间内归档切换次数
set timing on
set time on
set lines 200 pages 100
set COLSEP |
col id for 99
col DAY for a5
COLUMN H00 FORMAT 999 HEADING 00
COLUMN H01 FORMAT 999 HEADING 01
COLUMN H02 FORMAT 999 HEADING 02
COLUMN H03 FORMAT 999 HEADING 03
COLUMN H04 FORMAT 999 HEADING 04
COLUMN H05 FORMAT 999 HEADING 05
COLUMN H06 FORMAT 999 HEADING 06
COLUMN H07 FORMAT 999 HEADING 07
COLUMN H08 FORMAT 999 HEADING 08
COLUMN H09 FORMAT 999 HEADING 09
COLUMN H10 FORMAT 999 HEADING 10
COLUMN H11 FORMAT 999 HEADING 11
COLUMN H12 FORMAT 999 HEADING 12
COLUMN H13 FORMAT 999 HEADING 13
COLUMN H14 FORMAT 999 HEADING 14
COLUMN H15 FORMAT 999 HEADING 15
COLUMN H16 FORMAT 999 HEADING 16
COLUMN H17 FORMAT 999 HEADING 17
COLUMN H18 FORMAT 999 HEADING 18
COLUMN H19 FORMAT 999 HEADING 19
COLUMN H20 FORMAT 999 HEADING 20
COLUMN H21 FORMAT 999 HEADING 21
COLUMN H22 FORMAT 999 HEADING 22
COLUMN H23 FORMAT 999 HEADING 23SELECT
THREAD# id,SUBSTR(TO_CHAR(first_time, MM/DD/RR HH:MI:SS),1,5) DAY
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),00,1,0)) H00
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),01,1,0)) H01
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),02,1,0)) H02
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),03,1,0)) H03
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),04,1,0)) H04
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),05,1,0)) H05
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),06,1,0)) H06
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),07,1,0)) H07
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),08,1,0)) H08
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),09,1,0)) H09
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),10,1,0)) H10
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),11,1,0)) H11
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),12,1,0)) H12
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),13,1,0)) H13
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),14,1,0)) H14
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),15,1,0)) H15
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),16,1,0)) H16
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),17,1,0)) H17
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),18,1,0)) H18
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),19,1,0)) H19
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),20,1,0)) H20
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),21,1,0)) H21
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),22,1,0)) H22
, SUM(DECODE(SUBSTR(TO_CHAR(first_time, MM/DD/RR HH24:MI:SS),10,2),23,1,0)) H23
FROM
v$log_history a
WHERE first_time SYSDATE - NumberOfDays -- Replace NumberOfDays with the number of days you want to query
GROUP BY SUBSTR(TO_CHAR(first_time, MM/DD/RR HH:MI:SS),1,5),THREAD#
ORDER BY id,SUBSTR(TO_CHAR(first_time, MM/DD/RR HH:MI:SS),1,5)
/
NumberOfDays以在运行查询时被提示输入这个值
输入 30查询 30天内归档的切换频率 5.3.2.2. 查询归档量
select THREAD#,
logtime,
count(*),
round(sum(blocks * block_size) / 1024 / 1024 / 1024) GBsize
from (select THREAD#,
trunc(first_time, hh) as logtime,
a.BLOCKS,
a.BLOCK_SIZE
from v$archived_log a
where a.DEST_ID 1
and a.FIRST_TIME trunc(sysdate - NumberOfDays))
group by THREAD#, logtime
order by THREAD#, logtime desc
/
NumberOfDays以在运行查询时被提示输入这个值
输入 30查询 30天内归档量 5.4. 失效对象及索引管理
在 Oracle 数据库中失效的对象例如过时的或编译错误的存储过程、函数、包、触发器等可能会导致性能问题或运行时错误。检查和修复这些失效对象通常是数据库维护工作的一部分。同样对于索引需要检查是否有无效或不可用的索引。
5.4.1. 检查失效对象
SELECT owner,
object_type,
object_name,
status
FROM dba_objects
WHERE status ! VALID
and owner!SYS and owner!SYSTEM
ORDER BY 1,2,3;
5.4.2. 修复失效对象
对于失效的对象可以尝试重新编译。
ALTER PROCEDURE schema.procedure_name COMPILE;
ALTER FUNCTION schema.function_name COMPILE;
ALTER PACKAGE schema.package_name COMPILE;
-- 等等针对每种类型的对象。 5.4.3. 检查失效索引
SELECT owner,
index_name,
table_name,
status
FROM dba_indexes
WHERE status ! VALID
ORDER BY 1,2,3; 5.4.4. 修复失效索引
对于失效的索引可以尝试重建
ALTER INDEX schema.index_name REBUILD;
5.5. 索引层分析
索引需要维护。对于表的删除或者添加操作都会间接地对索引进行相应操作。过时的索引结构会产生碎片此时索引需要被重新建立。
BLEVEL是B-tree索引形式的一部分与Oracle为搜索某些纪录而减少索引搜索的次数相关联。在一些情况下BLEVEL需要单独的磁盘命中。In some cases, a separate disk hit is requested for each BLEVEL如果 BLEVEL大于4那么建议重建索引。
select
owner,
table_name,
index_name,
BLEVEL
from dba_indexes
where BLEVEL 3
and owner not in (SYS, SYSTEM, OUTLN, DBSNMP, ORDSYS,
ORDPLUGINS, SYSMAN,MDSYS, CTXSYS, AURORA$ORB$UNAUTHENTICATED, XDB,EXFSYS,FLOWS_030000,OLAPSYS,SCOTT,TSMSYS,WKSYS,WK_TEST,WMSYS,ORDDATA)
order by 1,2,3;
5.6. 查询数据库等待事件
查询的目的是列出 Oracle 数据库中所有非空闲等待事件的会话数量,分析数据库等待事件识别性能瓶颈。
select inst_id,event#,event,count(*)
from gv$session where wait_class#6
group by inst_id,event#,event
order by 1,4; 5.6.1. 常见非空闲等待事件
在 Oracle 数据库中非空闲等待事件通常指的是那些可能表示性能瓶颈或资源争用的等待事件。以下是常见的非空闲等待事件及其含义
5.6.1.1. Direct Path Read
描述: Direct path read 是 Oracle 数据库的一种读取机制它绕过了缓冲区缓存直接从磁盘读取数据到 PGA (程序全局区) 中。这种机制通常用于大量数据的读取操作如排序、哈希联接、大型表的全表扫描或并行查询。当执行这些操作时Oracle 判断使用直接路径读取比通过缓冲区缓存更为有效率。 潜在问题:
I/O 性能: 如果 I/O 子系统不足以快速处理直接路径读取请求可能会导致性能瓶颈。
大量数据操作: 查询可能导致大量数据被读取而不是使用索引或其他更高效的数据访问方法。
缓冲区缓存绕过: 直接路径读取不使用数据库缓冲区缓存可能导致该缓存的优化失效。 解决方案:
查询优化: 重新评估并优化导致大量直接路径读取的 SQL 查询以更有效地使用索引或减少需要读取的数据量。
I/O 优化: 提升磁盘 I/O 性能可能包括使用更快的存储介质、优化存储配置或增加并行度。
资源分配: 优化 PGA 的分配和大小以确保有足够的内存处理直接路径读取操作。
并行执行策略: 对于大型操作评估并行执行策略和参数确保并行度与系统资源相匹配。
存储管理: 对于频繁进行大量数据读取的表考虑使用自动存储管理功能如 Oracle ASM和高速缓存如 Exadata 的 Smart Scan 特性。 5.6.1.2. asm file metadata operation
描述: 在 Oracle Automatic Storage Management (ASM) 环境中ASM 文件元数据操作相关的等待事件通常指示会话正在等待完成与 ASM 文件的元数据相关的操作。这些操作可能包括文件的创建、删除、重命名或获取文件属性等。 潜在问题:
元数据争用: 多个会话或节点同时尝试访问或修改 ASM 文件的元数据。
I/O 性能: 磁盘 I/O 性能不足尤其是在访问磁盘组的元数据时。
ASM 配置: ASM 实例的配置不当可能导致性能瓶颈。 解决方案:
监控和诊断: 使用 Oracle 提供的工具如 ASMcmd、Grid Control 或 SQL*Plus监控 ASM 实例和磁盘组的性能。
并发控制: 避免在高峰期执行大量的文件元数据操作以减少争用。
性能调优: 优化 ASM 磁盘组的布局确保元数据操作可以高效执行。
资源优化: 调整磁盘组的冗余级别和条带大小以改善性能。
ASM 实例优化: 调整 ASM 实例的参数如 ASM_DISKGROUPS以确保磁盘组能够高效响应元数据操作。
存储硬件评估: 检查底层存储硬件的性能和配置确保其能够支持 ASM 的操作需求。 5.6.1.3. db file sequential read
描述: db file sequential read是 Oracle 数据库中的一个等待事件通常与读取索引块有关。这种等待事件发生在执行索引查找如使用唯一索引或非唯一索引访问表行时数据库从磁盘同步读取单个数据块到缓冲区中。这个等待事件指示的是每次读取一个数据块的延迟。 潜在问题:
索引访问效率: 频繁的索引访问可能指示查询效率不高或索引设计不当。
I/O 性能: 如果磁盘 I/O 性能不佳会导致读取单个块的时间增加。
数据分布: 数据可能在磁盘上分布不均导致访问某些数据块时延迟较高。 解决方案:
优化索引和查询: 分析和优化执行计划确保查询有效地使用索引。对于频繁访问的表考虑添加或优化索引。
提升 I/O 性能: 检查存储子系统的性能。使用 RAID 配置、更快的硬盘或 SSD 可以提升读取性能。
数据重组: 对数据库表进行重组以改善数据的物理排列和降低碎片化。
缓存优化: 调整数据库缓冲区大小以保留更多的数据块并减少对磁盘的访问。
存储管理: 确保数据文件分布在高性能的磁盘上并且平衡 I/O 负载。
SQL 性能分析: 使用 Oracle 的 SQL Tuning Advisor 或类似工具分析和优化长时间运行的 SQL 语句。 5.6.1.4. db file scattered read
描述: db file scattered read等待事件通常发生在 Oracle 执行全表扫描或大范围的索引扫描时。在这种情况下数据库从磁盘读取多个数据块并“分散”它们到数据库缓冲区中的不同位置。这种 I/O 操作是异步的意味着可以同时读取多个块。 潜在问题:
全表扫描: 查询可能无法有效利用索引导致必须从磁盘读取大量数据。
索引设计: 索引可能不适用于当前的查询或者根本不存在合适的索引。
I/O 性能: 数据库执行大量的 I/O 操作可能因磁盘性能不佳而导致延迟。 解决方案:
SQL 优化: 重新评估和优化导致全表扫描的 SQL 查询。使用如 EXPLAIN PLAN 的工具分析执行计划确保查询能有效利用索引。
索引管理: 创建或优化索引以提高查询效率。分析查询的 WHERE 子句和 JOIN 条件确定是否可以通过添加新索引来优化查询。
表分区: 对于大型表考虑实施表分区策略。表分区可以提高大表的管理效率和查询性能。
I/O 子系统优化: 检查和优化 I/O 子系统。考虑使用更快的磁盘如 SSD或优化磁盘阵列和 RAID 配置。
并行查询: 对于涉及大量数据的查询考虑使用并行查询来加速处理。
数据库缓存调整: 增大数据库的缓冲区缓存DB Cache可以减少对磁盘的访问。 5.6.1.5. log file sync
描述: log file sync等待事件发生在事务提交时数据库在等待将事务中的重做日志信息从重做日志缓冲区写入到磁盘上的在线重做日志文件中。这是一个关键的同步操作因为事务必须等待这个写入完成才能被视为成功提交。 潜在问题:
频繁提交: 应用程序可能执行了大量的小事务导致频繁的日志刷新。
I/O 性能: 如果重做日志文件所在的磁盘性能不足会导致写入操作变慢。
网络延迟: 在 RAC 环境中网络延迟可能导致跨节点的日志写入变慢。 解决方案:
优化事务提交: 如果可能批量处理事务提交减少事务提交的频率。
重做日志配置: 将重做日志文件放置在更快的磁盘上例如使用 SSD。
调整日志缓冲区: 增加日志缓冲区的大小可以减少写入磁盘的频率但需谨慎进行以避免影响其他内存需求。
I/O 子系统优化: 检查和优化重做日志文件所在的存储子系统。
日志文件管理: 均衡分配重做日志文件避免单个磁盘的过载。
RAC 环境优化: 在 RAC 环境中优化节点间的网络通信以减少延迟。 5.6.1.6. log file parallel write
描述: log file parallel write 等待事件通常涉及到 Oracle 数据库后台进程如 LGWR日志写入器将重做日志缓冲区中的数据并行写入所有在线重做日志文件。这是一个关键的写入操作影响着事务的提交性能。 潜在问题:
I/O 子系统性能: 如果写入日志文件的磁盘性能不足可能导致写入操作变慢。
重做日志文件配置: 重做日志文件的大小、数量或位置配置不佳可能导致写入效率低下。
系统负载: 高事务率增加了日志写入器的负载。 解决方案:
优化存储配置: 使用更快的存储介质如 SSD来存储重做日志文件。
日志文件分布: 将重做日志文件分散到多个磁盘上以平衡 I/O 负载。
增加日志文件数量: 增加重做日志文件的数量可以减少单个文件的 I/O 压力。
日志文件大小: 确保重做日志文件大小适合于事务量避免过小的日志文件导致频繁的日志切换。
监控系统性能: 定期监控系统的 I/O 性能确保日志写入操作不成为瓶颈。
减少日志写入需求: 优化应用逻辑减少不必要的日志生成如减少不必要的事务。 5.6.1.7. latch free
描述: latch free 等待事件发生在一个 Oracle 会话试图获取一个闩锁latch而该闩锁已被另一个会话持有时。闩锁是一种轻量级的内部锁机制用于保护数据库的共享数据结构比如缓冲区缓存或共享池。这个等待事件通常表示内存结构访问的高并发。 潜在问题:
高并发访问: 如果多个会话并发访问相同的内存结构可能导致闩锁争用。
内存结构热点: 某些内存结构如共享池或缓冲区缓存成为热点频繁被访问。
数据库配置: 数据库参数配置不当可能导致特定闩锁的争用。 解决方案:
性能监控与分析: 使用 Oracle 的性能监控工具如 AWR、ADDM来识别哪些闩锁经常被争用以及这些争用的原因。
优化数据库配置: 根据性能分析的结果调整相关数据库参数如增加共享池大小或调整缓冲区缓存的设置。
减少热点争用: 识别并优化导致热点争用的 SQL 语句或应用逻辑。
合理分配资源: 确保系统资源如 CPU、内存被合理分配和使用避免资源瓶颈。
应用优化: 调整应用程序逻辑减少对高争用内存结构的访问频率。
代码优化: 避免在数据库代码中如 PL/SQL使用大量的动态 SQL这可能增加对共享池的争用。 5.6.1.8. buffer busy waits
描述: buffer busy waits 等待事件在 Oracle 数据库中发生时指示一个会话正在等待访问缓冲区缓存中的数据块而该数据块正被另一个会话所使用。这通常出现在多个会话尝试同时访问同一个数据块时例如当多个会话试图读取或修改同一行时或者在进行并发插入到同一个表块时。 潜在问题:
热点数据块: 高并发访问同一数据块可能是表中的热点行或索引热点。
I/O 同步问题: 同步 I/O 操作增加了对特定块的争用。
表设计问题: 例如对于高并发插入可能由于使用了单一的表分区或不适当的 PCTFREE 和 PCTUSED 设置。 解决方案:
减少热点: 识别并减少对热点数据块的访问。对于高并发插入的表考虑使用哈希分区或反向键索引来分散数据。
调整存储参数: 调整表的存储参数如 PCTFREE、PCTUSED 和 FREELISTS以减少对单个数据块的竞争。
并行处理: 对于大量的批量数据操作考虑使用并行处理来分散负载。
I/O 优化: 优化表和索引的物理存储例如通过使用自动存储管理ASM或在更快的磁盘上存储高访问表。
监控和分析: 使用性能监控工具分析具体的 buffer busy waits 事件以确定争用的确切原因和位置。
应用逻辑优化: 优化应用逻辑减少对特定热点数据块的并发访问。 5.6.1.9. library cache lock / library cache pin 描述: 这两种等待事件都与 Oracle 数据库的库缓存library cache相关。库缓存是共享池shared pool的一部分用于存储可重用的代码和数据例如 SQL 语句、PL/SQL 代码和对象定义。
library cache lock: 发生在会话需要修改库缓存中的对象如 SQL 语句、包、过程等时而必须等待获取对该对象的排他锁。
library cache pin: 当会话需要执行库缓存中的对象如执行一个 PL/SQL 函数而必须等待获取对该对象的访问钉pin以防止在执行期间对象被卸载或改变。 潜在问题:
硬解析过多: 频繁的硬解析导致库缓存对象频繁加载和卸载。
共享对象的竞争: 高并发环境中对同一共享对象的争用。
不当的应用设计: 应用程序设计可能导致对共享对象的频繁修改或执行。 解决方案:
减少硬解析: 通过使用绑定变量和写好的 SQL 语句来减少硬解析促进 SQL 语句的重用。
优化共享池大小: 调整共享池的大小确保有足够的空间用于库缓存。
避免频繁修改: 减少对共享库缓存对象如包、过程的频繁修改。
优化应用逻辑: 检查和优化那些可能频繁访问或修改共享对象的应用程序代码。
监控和诊断: 使用性能诊断工具如 AWR、ADDM监控库缓存的使用情况和等待事件以识别热点和性能瓶颈。
代码优化: 在 PL/SQL 中避免使用动态 SQL尤其是在高并发场景中。 5.6.1.10. row cache lock 描述: row cache lock 等待事件发生在 Oracle 数据库中指的是会话等待访问数据字典缓存中的某个对象时的延迟。数据字典缓存也称为行缓存存储了数据库对象的元数据信息例如用户表和索引的定义。当会话需要修改或查询这些对象的元数据时可能需要获取对应的锁。 潜在问题:
数据字典争用: 如果多个会话试图并发修改数据字典比如频繁创建、修改或删除表和索引可能会导致争用。
长时间运行的 DDL 操作: 某些数据定义语言DDL操作可能占用行缓存锁较长时间导致其他会话等待。
不当的应用设计: 应用程序可能包含导致数据字典频繁访问或修改的设计问题。 解决方案:
避免高峰时段执行 DDL: 尽量在系统负载较低的时候执行数据字典的修改操作如表的创建、修改或删除。
优化应用逻辑: 调整应用逻辑减少对数据字典的频繁访问或修改。
监控和诊断: 使用 Oracle 的监控工具如 SQL Trace、TKPROF、AWR监控数据字典的访问以识别并解决性能瓶颈。
增加数据字典缓存大小: 如果经常发生行缓存锁争用考虑增加 row cache 的大小。
代码优化: 检查数据库代码避免不必要的动态 DDL 操作特别是在事务处理中。
序列和触发器管理: 对于使用序列和触发器的应用确保它们的管理和使用不会导致数据字典的过度争用。 5.6.1.11. SQL*Net message to client / from client
描述:
SQL*Net message to client: 这个等待事件发生在服务器向客户端发送消息时。它通常是一个非常快的操作因为它涉及到向客户端发送数据包。
SQL*Net message from client: 这个等待事件发生在服务器等待来自客户端的消息时。这通常涉及到等待客户端响应或发送下一个请求。 潜在问题:
网络延迟: 对于两个事件网络延迟都可能是一个重要因素。慢的网络连接会增加服务器等待客户端响应的时间。
客户端处理: 对于 from client 事件客户端处理速度可能影响等待时间。例如如果客户端在请求之间执行复杂的处理或计算服务器可能需要等待更长时间。
应用设计: 应用程序设计可能导致频繁的往返通信增加了等待时间。 解决方案:
优化网络: 检查和优化网络连接和配置确保网络通信是高效的。对于分布式应用考虑使用更快的网络解决方案或优化网络路由。
客户端优化: 优化客户端应用程序的性能减少在发送响应之前所做的处理。
减少往返次数: 优化应用程序逻辑减少数据库和应用程序之间的往返次数。例如通过一次请求发送更多的数据或减少不必要的数据库请求。
使用有效的数据获取策略: 例如使用批量操作或更有效的查询以减少网络往返次数和数据传输量。
SQL 和应用代码优化: 确保 SQL 查询和应用程序代码是高效的以减少等待和处理时间。
调整 SQL*Net 参数: 调整 SQL*Net 配置如 SDU (Session Data Unit) 大小以优化数据包的传输。 5.6.2. 常见gc (Global Cache) 非空闲等待事件
在 Oracle Real Application Clusters (RAC) 环境中除了单实例数据库中常见的非空闲等待事件外还有一些等待事件特别与 RAC 的架构和并发操作有关。以下是一些在 RAC 环境中常见的非空闲等待事件 5.6.2.1. gc cr block 2-way / gc cr block 3-way:
描述:
gc cr block 2-way: 这个等待事件发生在一个节点需要访问另一个节点上的数据块的一致性读Consistent Read, CR副本时。2-way 指的是数据块已经在另一个节点的内存中只需要通过网络传输到请求节点。
gc cr block 3-way: 类似于 gc cr block 2-way但这里的 3-way 指的是数据块不在另一个节点的内存中需要先从磁盘读取到该节点的内存然后再通过网络传输到请求节点。
潜在问题:
网络延迟: 在节点间传输数据块可能受到网络延迟的影响。
数据块热点: 某些数据块可能在多个节点之间频繁共享造成热点和性能瓶颈。
I/O 性能: 对于 gc cr block 3-way如果远程节点上的 I/O 性能不足可能导致读取数据块到内存的延迟。
解决方案:
优化网络配置: 确保 RAC 节点间的网络高效且低延迟。考虑使用专用的高速网络硬件和配置。
减少数据块传输: 通过优化应用程序和数据库设计来减少不同节点间的数据块传输。例如通过数据分区、负载均衡或 RAC 亲和性策略。
监控和分析: 使用 Oracle RAC 的监控工具来识别和分析哪些数据块在节点间频繁传输并探索优化方法。
优化 I/O 性能: 对于 gc cr block 3-way确保所有节点上的 I/O 系统都足够快以避免读取磁盘数据的延迟。
应用和查询优化: 优化 SQL 查询和应用程序逻辑以减少对远程节点数据的访问特别是对于高访问频率的数据块。
数据局部性: 尽可能在应用层或数据库设计层实现数据的局部性减少跨节点的数据依赖。 5.6.2.2. gc buffer busy:
描述:
这个等待事件发生在一个节点尝试访问另一个节点上的数据块时但无法立即进行因为那个数据块正在被远程节点上的另一个进程所使用。这种情况通常发生在多个节点试图同时访问和修改同一个数据块时。
潜在问题:
跨节点的数据块争用: 如果多个节点频繁访问和修改同一个数据块可能会导致此等待事件。
RAC 环境配置: RAC 环境的配置包括网络设置和数据块访问模式可能影响全局缓存的性能。
应用设计: 应用程序设计可能导致数据热点特别是当多个节点频繁访问同一数据集时。
解决方案:
数据局部性优化: 尽可能在设计应用时实现数据的局部性减少跨节点数据访问。通过分区、数据分布策略等方式来实现。
负载均衡: 确保 RAC 系统的负载均衡避免单个节点上的数据热点。
网络优化: 检查和优化 RAC 节点间的网络连接确保高效、低延迟的数据块传输。
SQL 和事务优化: 优化高频访问的 SQL 查询和事务处理逻辑减少对同一数据块的竞争。
监控和分析: 利用 Oracle 提供的工具如 AWR、ASH、Grid Control来监控和分析 RAC 环境中的等待事件特别关注那些导致 gc buffer busy 的操作。
应用调整: 考虑修改应用逻辑或数据库设计以减少对特定数据块的并发访问。 5.6.2.3. gc busy:
描述:
这个等待事件发生在一个 RAC 节点在等待另一个节点完成其对全局缓存资源的操作时。这通常涉及到跨节点的数据块传输或全局资源管理。当一个节点正在处理一个全局缓存操作如获取数据块而另一个节点也想要对同一数据块执行操作时可能会出现 gc busy 等待。
潜在问题:
跨节点通信效率: 网络延迟或配置不当可能导致节点间通信效率低下增加等待时间。
全局资源争用: 多个节点竞争同一资源如特定的数据块可能导致这种等待。
RAC 环境配置: RAC 配置特别是与全局资源管理相关的配置可能影响这种等待的频率和时长。
解决方案:
网络优化: 检查并优化 RAC 节点间的网络配置确保低延迟和高带宽。
减少全局资源争用: 分析和优化数据库操作减少对全局资源的争用。可以通过调整数据分布、改变应用访问模式或优化 SQL 查询来实现。
RAC 配置调整: 审查和调整 RAC 环境的配置特别是与全局缓存和资源管理相关的参数。
负载均衡: 通过 RAC 负载均衡特性确保数据库负载在不同节点间均衡分配。
监控和分析: 使用 Oracle 的监控工具如 AWR、Grid Control定期监控 RAC 环境特别关注导致 gc busy 等待的操作和数据块。
应用程序调整: 考虑修改应用程序的数据访问模式减少对特定数据块或全局资源的并发访问。 5.6.2.4. global enqueue waits:
描述:
global enqueue waits 等待事件发生在一个 RAC 节点等待获取跨节点共享的锁enqueue时。这些锁用于协调多个节点之间对共享资源如数据块、表结构等的访问。这个等待事件指示一个节点正在等待另一个节点释放锁或授予访问权限。
潜在问题:
资源争用: 在多个节点上对相同资源例如表或行的高并发访问可能导致锁争用。
网络延迟: 节点间通信延迟可能增加等待时间特别是在锁请求和释放过程中。
锁管理效率: RAC 环境中锁的管理效率可能受到配置和现有负载的影响。
解决方案:
应用设计优化: 调整应用程序逻辑以减少对全局资源的并发访问特别是减少对跨节点共享资源的写操作。
分区和数据分布: 通过合理的数据分区和放置策略减少不同节点间对同一数据的访问。
网络优化: 确保 RAC 环境的网络配置优化减少节点间通信的延迟。
事务管理: 优化事务大小和持续时间避免长时间持有锁。
监控和诊断: 使用 Oracle 提供的工具如 AWR、Grid Control 来监控锁争用情况识别热点资源。
RAC 配置调整: 调整与 RAC 锁相关的数据库参数优化全局资源管理。
5.6.2.5. gcs log flush sync:
描述:
gcs log flush sync等待事件发生在 RAC 环境中当一个节点需要等待另一个节点确认重做日志信息已经被成功记录到磁盘时。这通常与 RAC 中事务提交的日志同步有关确保跨节点的数据一致性。
潜在问题:
跨节点日志写入延迟: 如果另一个节点写入重做日志到磁盘的速度慢可能会导致等待时间增加。
网络延迟: 节点间通信的延迟也可能增加等待时间尤其是在传输日志确认信息时。
I/O 子系统性能: 另一个节点的 I/O 子系统性能不足可能导致写入日志缓慢。
解决方案:
优化网络通信: 确保 RAC 节点间的网络高效且低延迟。可能需要检查和优化网络配置或硬件。
提升日志写入性能: 确保所有节点上的重做日志文件都存储在高性能的 I/O 系统上如使用 SSD。
平衡负载: 确保 RAC 环境中的事务负载在各个节点之间均衡分布避免单一节点过载。
日志配置优化: 检查并优化重做日志配置包括日志文件大小和位置以提高整体写入性能。
监控和诊断: 使用 Oracle 的监控工具如 AWR、Grid Control来监控日志同步操作和相关的性能指标。
RAC 参数调整: 调整与日志写入和同步相关的 RAC 参数优化性能。 5.7. 会话和事务
5.7.1. 活跃会话监控
5.7.1.1. 查询会话数
SELECT inst_id, username, status, type, COUNT(*) AS session_count
FROM gv$session
GROUP BY inst_id, username, status, type
ORDER BY inst_id, username, status, type;
这个查询将每个实例中不同状态和类型的会话数量,会话按其状态如活跃、空闲和类型如前台用户会话、后台进程分组并统计每组的会话数量。 5.7.2. SQL执行分析
5.7.2.1. 查询非活跃会话
SELECT s.inst_id, s.sid, s.serial#, s.username, s.status, s.last_call_et, s.sql_id
FROM gv$session s
WHERE s.status INACTIVE
ORDER BY s.last_call_et DESC; 5.7.2.2. 查询长时间运行的SQL语句
select inst_id,sid,SERIAL#,SQL_ID,username,opname,START_TIME,TIME_REMAINING REMAIN,ELAPSED_SECONDS ELAPSE,MESSAGE,QCSID
from gv$session_longops
where TIME_REMAINING 0; 5.7.3. 锁管理
5.7.3.1. 查询数据库中的锁定和等待情况
select decode(request, 0, Holder:, Waiter:) || s.inst_id || : ||s.sid || , || s.serial# sess,id1,id2,lmode,request,l.type,d.object_name,d.object_type,ctime,s.sql_id,s.event,s.last_call_etfrom gv$lock l, gv$session s, dba_objects dwhere (id1, id2, l.type) in(select id1, id2, type from gv$lock where request 0)and l.sid s.sidand l.inst_id s.inst_idand s.ROW_WAIT_OBJ# d.object_id()order by id1, ctime desc, request;一个是锁的持有者Holder另一个是等待者Waiter。这表示存在锁争用其中一个会话持有资源锁并且另一个会话正在等待这个锁。
字段解析
SESS: 描述会话的信息格式为 [状态]:[实例ID]:[会话ID],[序列号]。例如Holder:1:1436,42045 表示实例 1 中的会话 ID 1436 和序列号 42045 是锁的持有者。相似地Waiter:2:1997,28543 表示实例 2 中的会话 ID 1997 和序列号 28543 是等待者。
ID1 和 ID2: 这些是锁标识符用于标识锁对象。
LMODE: 锁模式表示持有者的锁级别。
REQUEST: 请求模式表示等待者请求的锁级别。
TYPE: 锁类型此处显示为 TX表示事务锁。
OBJECT_NAME: 被锁定的对象名称在这个案例中为 LOCK_TEST 表。
OBJECT_TYPE: 被锁定对象的类型显示为 TABLE。
CTIME: 锁等待时间。
SQL_ID: 导致锁等待的 SQL 语句的标识符。
EVENT: 当前等待的事件对于 Waiter 显示为 enq: TX - row lock contention表示行级锁争用。
LAST_CALL_ET: 自上次调用以来的时间。 5.7.4. 解决锁争用
可以根据信息会话 IDSID和会话序列号Serial#杀死会话。
语法
ALTER SYSTEM KILL SESSION [会话ID],[序列号];ALTER SYSTEM KILL SESSION 1436,42045; 查找在数据库中已经等待超过 100 秒的会话锁并拼接对应杀会话SQL。
SELECT ALTER SYSTEM KILL SESSION || sid || , || serial# || ; AS kill_command
FROM v$session
WHERE SID IN (SELECT BLOCKER_SID FROM v$wait_chains WHERE IN_WAIT_SECS 100); 5.8. 数据库用户管理
5.8.1. 查询列出所有数据库用户及其属性
select USERNAME,ACCOUNT_STATUS,LOCK_DATE,EXPIRY_DATE,PROFILE,DEFAULT_TABLESPACE
from dba_users;
检查每个用户的账户状态如锁定、过期。
确认用户是否有适当的表空间分配。 5.8.2. 查询拥有DBA角色的用户
select GRANTEE,GRANTED_ROLE,ADMIN_OPTION,DEFAULT_ROLE
from DBA_ROLE_PRIVS
where GRANTED_ROLEDBA; 确保这些高权限账户仅限于需要这些权限来执行其职责的用户。
持续监控权限的使用情况确保遵循最小权限原则。
5.9. DataGuard管理
使用 v$dataguard_stats 视图检查数据保护和传输状态。使用 v$dataguard_stats 视图中的 apply lag 和 transport lag 指标来监控数据应用和传输的延迟时间
在备库上执行
select
NAME
, VALUE
, UNIT
, DATUM_TIME
, TIME_COMPUTED
from v$dataguard_stats
order by time_computed;
有延迟的同步 NAME: 数据列名代表不同的 Data Guard 监控指标。
transport lag: 传输延迟显示主库生成的数据与传输到备库之间的时间差。
estimated startup time: 预计启动时间可能指备库启动至可接受连接的估计时间。
apply finish time: 指示最后一个接收的日志应用到备库的完成时间。
apply lag: 应用延迟显示备库应用归档日志相比主库的延迟时间。 VALUE: 对应每个监控指标的值。 transport lag 的值是 00 00:00:00表示当前没有传输延迟。
estimated startup time 的值是 28 秒。
apply finish time 的值是 00 00:10:33.241这是指应用最后一个日志到备库所用的时间。
apply lag 的值是 53 07:18:00表示备库落后于主库超过 53 天的时间。 UNIT: 每个指标的单位。
transport lag 和 apply lag 的单位是 day(2) to second(0) interval这表示时间间隔以天和秒为单位。
estimated startup time 的单位是 second。
apply finish time 的单位是 day(2) to second(3) interval表示时间间隔精确到毫秒。
DATUM_TIME 和 TIME_COMPUTED: 这两列显示数据的采集时间和计算时间通常它们应该是一致的。在这里都显示为 01/08/2024 15:30:20 和 01/08/2024 15:30:21。
无延迟的同步 transport lag 和 apply lag值为 00 00:00:00 表示当前没有延迟。
estimated startup time值为 28 秒。
apply finish time 显示为 00 00:00:00.000意味着备库上的日志应用几乎没有延迟。 6. 备份和恢复策略
6.1. 备份状态
在数据库管理中确认最近的备份是否成功是至关重要的一环因为它直接关系到数据恢复的可行性。确认最近的备份是否成功
select
ELAPSED_SECONDS/3600 hour
, to_char(start_time,mm/dd hh24:mi:ss) start_time
, to_char(END_TIME,mm/dd hh24:mi:ss) end_time
, status
, input_type
, output_device_type devtype
, input_bytes_display inputmb
, output_bytes_display outputmb
, output_bytes_per_sec_display permb
from v$rman_backup_job_details
where start_time sysdate-3
order by start_time DESC
/ 6.2. 恢复策略验证
定期测试恢复策略以确保数据安全。审核备份策略确保它符合恢复时间目标 (RTO) 和恢复点目标 (RPO) 的要求。
6.2.1. 恢复策略验证的步骤
恢复演练:
定期进行全面的恢复演练以模拟真实的数据丢失情况并验证恢复过程和文档。
使用 RMAN 验证备份:
利用 RMAN 的 VALIDATE 命令检查备份的完整性。
例如执行 RMAN RESTORE DATABASE VALIDATE; 来验证数据库备份是否完整。
测试备份恢复:
在隔离环境中从备份中恢复数据库确保备份文件是可用的且能够完全恢复。
恢复点目标 (RPO) 验证:
确认备份频率和类型如全备份、增量备份符合业务对数据丢失的容忍度。
恢复时间目标 (RTO) 验证:
通过演练计算恢复整个数据库的实际时间确保其满足业务对恢复速度的要求。
自动化测试:
尽可能自动化恢复过程和测试减少人为错误并提高测试频率。
审计备份日志和历史记录:
定期检查备份作业的日志确保没有错误或警告。
审查备份配置:
确保备份策略包括备份级别、周期、保留策略符合业务和合规性要求。 6.2.2. 恢复策略验证的最佳实践
文档化:
确保所有恢复流程都有详细的文档并定期更新。
多样化备份:
使用多种备份方法和介质例如本地备份和离线备份以防单点故障。
监控和告警:
设置监控系统以跟踪备份和恢复操作的状态确保任何失败或异常都能立即获得响应。
权限和安全性:
确保只有授权的人员可以访问备份和执行恢复。 7. 查看警告和错误日志
7.1. 查看 Oracle 警告日志 (alert.log)
定位 alert.log 文件:
alert.log 文件通常位于 $ORACLE_BASE/diag/rdbms/dbname/instance_name/trace 确定数据库的确切路径可以通过 SQL 查询 SHOW PARAMETER BACKGROUND_DUMP_DEST; 检查日志内容:
使用文本编辑器或命令行工具如 less, tail, grep来查看 alert.log。
查找错误信息这些通常以 ORA- 开头。 grep 关键字 $ORACLE_BASE/diag/rdbms/dbname/instance_name/trace/alert_instance_name.log grep ORA- $ORACLE_BASE/diag/rdbms/dbname/instance_name/trace/alert_instance_name.log 注意检查任何异常的数据库行为如非计划的重启、性能问题、空间不足警告等。
定期审查:
定期如每天检查 alert.log以便及时发现并解决问题。
自动化监控:
通过脚本自动化 alert.log 的监控如使用 cron 定期执行并发送异常通知。
7.2. 查看集群日志
确定日志文件位置
在 Oracle RAC 中重要的日志文件包括 Oracle Clusterware 日志和数据库的 alert.log 文件。
日志路径$GRID_HOME/log/[节点名]/alert[节点名].log 例:$GRID_HOME/log/rac1/alertrac1.log 检查 Oracle Clusterware 日志
关注 crsd.log, cssd.log, evmd.log 等日志文件。
查找错误或异常这些通常标识为 ORA- 开头的错误代码。
使用文本查看器或命令行工具如 grep, tail, less来浏览和搜索日志内容。 tail -n 1000 /oracle/app/11.2.0/grid/log/rac1/alertrac1.log | grep ORA- 7.3. 检查操作系统日志
定位系统日志:
在 Linux 系统上系统日志通常位于 /var/log 目录例如 /var/log/messages 或 /var/log/syslog。
分析日志内容:
查找与硬件、网络或系统异常相关的错误和警告。
使用命令如 less, tail, 或 grep 来查看和筛选日志内容。 grep -i error\|warn\|fail /var/log/messages 相关性分析:
将操作系统日志中的异常与 Oracle alert.log 中的信息关联起来以获得更全面的故障图像。
