1. 检查服务器状态
1.1. CPU使用情况
1.1.1. top
top 命令是 Linux 和 Unix 系统中用于显示实时系统状态的工具,特别是对于监控 CPU 和内存的使用非常有用。
在命令行中输入 top,top 会显示一个实时更新的界面,其中包含系统的关键指标,如 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
vmstat(Virtual 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
vmstat(Virtual 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. 文件系统使用情况
df(disk 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):
第一个数据包的 RTT:0.210 毫秒
第二个数据包的 RTT:0.226 毫秒
统计数据:
最短 RTT:0.210 毫秒
平均 RTT:0.218 毫秒
最长 RTT:0.226 毫秒
RTT 波动(mdev):0.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.gsd(Global Services Daemon)是一个在 Oracle 10g RAC 和更早版本中用于支持服务管理功能的进程。从 Oracle 11g 开始,这个功能已被 Oracle Clusterware 的 ora.crsd(Cluster Ready Services Daemon)接管。
在 Oracle 11g 和更高版本中,ora.gsd 服务通常保持 OFFLINE 状态,因为它不再需要在新的集群管理架构中提供服务。因此,如果正在运行 Oracle 11g 或更高版本的 RAC,并且看到 ora.gsd 服务处于 OFFLINE 状态,这是正常现象,不会影响 RAC 的功能和性能。
检查集群中所有节点的状态:
crsctl check cluster -all
CRS-4537: 表明 Cluster Ready Services(CRS)是在线的。CRS 是 Oracle 集群的一个重要组成部分,负责管理和监控集群中的资源。
CRS-4529: 显示 Cluster Synchronization Services(CSS)也是在线的。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 (
SELECT
TS.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.STATUS
FROM
DBA_TABLESPACES TS,
(
SELECT
'D' TYPE,
TABLESPACE_NAME,
COUNT(*) TS_DF_COUNT,
SUM(BYTES) ALL_BYTES,
SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES)) MAXSIZ
FROM
DBA_DATA_FILES D
GROUP BY
TABLESPACE_NAME
UNION
ALL
SELECT
'T',
TABLESPACE_NAME,
COUNT(*) TS_DF_COUNT,
SUM(BYTES) ALL_BYTES,
SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES))
FROM
DBA_TEMP_FILES D
GROUP BY
TABLESPACE_NAME
) DF,
(
SELECT
TABLESPACE_NAME,
SUM(BYTES) FREESIZ,
MAX(BYTES)/1024/1024 NEXT_MAX_EXTENT_MB
FROM
DBA_FREE_SPACE
GROUP BY
TABLESPACE_NAME
UNION
ALL
SELECT
TABLESPACE_NAME,
SUM(D.BLOCK_SIZE * A.BLOCKS) BYTES,
NULL
FROM
GV$SORT_USAGE A,
DBA_TABLESPACES D
WHERE
A.TABLESPACE = D.TABLESPACE_NAME
GROUP BY
TABLESPACE_NAME
) FS
WHERE
TS.TABLESPACE_NAME = DF.TABLESPACE_NAME
AND TS.TABLESPACE_NAME = FS.TABLESPACE_NAME(+)
)
SELECT
(
SELECT
A.TS#
FROM
V$TABLESPACE A
WHERE
A.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
FROM
WT1 T
UNION
ALL
SELECT
TO_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
FROM
WT1 T
ORDER BY
USED_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_G"
from dba_data_files A,
DBA_FREE_SPACE B,
v$DATAFILE d
WHERE A.FILE_ID=B.FILE_ID(+) and A.FILE_ID=d.FILE#
group by a.file_id,A.online_status,d.creation_time,A.AUTOEXTENSIBLE,A.MAXBYTES/1024/1024/1024
order by 1,6;
5.1.2. 临时表空间
5.1.2.1. 检查临时表空间使用率:
SELECT
D.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 %"
FROM
SYS.DBA_TABLESPACES D,
(
SELECT
TABLESPACE_NAME,
SUM(BYTES) BYTES
FROM
DBA_TEMP_FILES
GROUP BY
TABLESPACE_NAME
) A,
(
SELECT
TABLESPACE_NAME,
SUM(BYTES_CACHED) BYTES_CACHED,
SUM(BYTES_USED) BYTES_USED
FROM
GV$TEMP_EXTENT_POOL
GROUP BY
TABLESPACE_NAME
) T
WHERE
D.TABLESPACE_NAME = A.TABLESPACE_NAME(+)
AND D.TABLESPACE_NAME = T.TABLESPACE_NAME(+)
AND D.EXTENT_MANAGEMENT LIKE 'LOCAL'
AND 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.TABLESPACE
from gv$TEMPSEG_USAGE a, gv$SESSION b
where a.inst_id=b.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 MGMT"
FROM 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) bytes
FROM (SELECT tablespace_name, sum(bytes) bytes, status from dba_undo_extents WHERE status = 'ACTIVE' group by tablespace_name, status
UNION ALL
SELECT 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_mb
from dba_undo_extents
group by owner, tablespace_name, status) a,
(select tablespace_name, sum(bytes) / 1024 / 1024 total_mb
from 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_IO
from gv$session s, gv$transaction t, v$rollname r
where s.saddr = t.SES_ADDR and r.usn = t.xidusn and s.inst_id=t.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 '23'
SELECT
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_et
from gv$lock l, gv$session s, dba_objects d
where (id1, id2, l.type) in
(select id1, id2, type from gv$lock where request > 0)
and l.sid = s.sid
and l.inst_id = s.inst_id
and 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. 解决锁争用
可以根据信息会话 ID(SID)和会话序列号(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_ROLE='DBA';
确保这些高权限账户仅限于需要这些权限来执行其职责的用户。
持续监控权限的使用情况,确保遵循最小权限原则。
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 中的信息关联起来,以获得更全面的故障图像。