Oracle 日常巡检
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 (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,(SELECT'D' TYPE,TABLESPACE_NAME,COUNT(*) TS_DF_COUNT,SUM(BYTES) ALL_BYTES,SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES)) MAXSIZFROMDBA_DATA_FILES DGROUP BYTABLESPACE_NAMEUNIONALLSELECT'T',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_G"from dba_data_files A,DBA_FREE_SPACE B,v$DATAFILE dWHERE 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/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 '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.TABLESPACEfrom 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) 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_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_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. 解决锁争用
可以根据信息会话 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 中的信息关联起来,以获得更全面的故障图像。
相关文章:
Oracle 日常巡检
1. 检查服务器状态 1.1. CPU使用情况 1.1.1. top top 命令是 Linux 和 Unix 系统中用于显示实时系统状态的工具,特别是对于监控 CPU 和内存的使用非常有用。 在命令行中输入 top,top 会显示一个实时更新的界面,其中包含系统的关键指标&am…...
CS 144 check7: putting it all together
Exercises 经验:两边的TCP连接建立得尽快,如果服务器端启动了,客户端没有启动就连不上。。 服务器端: 客户端: 文件收发测试: 参考: CS 144CS144 | Winter 2024, Lab 0~7 记录࿰…...
springboot数据校验报错
目录 报错信息 原因 解决 报错信息 springboot在进行数据校验的时候ConfigurationProperties注解形式下Email报错 Caused by: javax.validation.UnexpectedTypeException: HV000030: No validator could be found for constraint javax.validation.constraints.Email valid…...
mapbox基础,加载天地图矢量底图
👨⚕️ 主页: gis分享者 👨⚕️ 感谢各位大佬 点赞👍 收藏⭐ 留言📝 加关注✅! 👨⚕️ 收录于专栏:mapbox 从入门到精通 文章目录 一、🍀前言1.1 ☘️mapboxgl.Map 地图对象…...
SLAM/数字图象处理基础
概念 视差:相同特征的不同深度估计的偏差 BoW,DBoW,DBoW2的区别是什么 Bag of Words (BoW)、DBoW(Dynamic Bag of Words)和DBoW2是用于图像处理和计算机视觉中的不同特征表示和匹配方法。它们之间的主要区别如下&am…...
修改vue-element-admin,如何连接我们的后端
改哪几个文件就可以连接我们后端 主要就这四个 main.js,屏蔽这个或者删除 vue-config 最后两个文件改下端口即可 这样基本就能发了,但是还要改下 改成api 然后还要修改request.js 这里改成我们返回的状态码 我讲一个东西很容易就懂了&…...
基于PLC的采摘机械手系统(论文+源码)
1系统方案设计 本次设计围绕基于PLC的采摘机械手系统进行设计, PLC即可编程控制器其是一种常见的微处理器,本次拟采用西门子是S7-200 PLC,一方面对整个设计从器件选型到I/O分配,图纸绘制等进行设计,另一方面还通过组态…...
使用ArcGIS/ArcGIS pro绘制六边形/三角形/菱形渔网图
在做一些尺度分析时,经常会涉及到对研究区构建不同尺度的渔网进行分析,渔网的形状通常为规则四边形。构建渔网的方法也很简单,使用ArcGIS/ArcGIS Pro工具箱中的【创建渔网/CreateFishnet】工具来构建。但如果想构建其他形状渔网进行相关分析&…...
【5/6 面向应用相关的优化 网卡实现及评估 】
5 面向应用相关的优化 面对数据中心多样化的部署需求和应用场景,如分布式存储、多租户性能隔离等,构建高性能的RDMA系统需要仔细选择传输模式和通信原语以充分发挥其性能优势,并调整软硬件结构进行适配.整体手段:在软件层面结合R…...
如何识别钓鱼邮件和诈骗网站?(附网络安全意识培训PPT资料)
识别钓鱼邮件和诈骗网站是网络安全中的一个重要环节。以下是一些识别钓鱼邮件和诈骗网站的方法: 识别钓鱼邮件: 检查发件人地址: 仔细查看发件人的电子邮件地址,看是否与官方域名一致。 检查邮件内容: 留意邮件中是否…...
TOGAF之架构标准规范-业务架构
TOGAF标准规范中,业务架构阶段的主要工作是开发支持架构愿景的业务架构。 如上所示,业务架构(Business Architecture)在TOGAF标准规范中处于B阶段,该阶段的主要内容包括阶段目标、阶段输入、流程步骤、架构方法。 阶段…...
嵌入式轻量级开源操作系统:HeliOS的使用
嵌入式轻量级开源操作系统:HeliOS的使用 📍项目地址:https://github.com/heliosproj/HeliOS HeliOS项目是一个社区交付的开源项目,用于构建和维护HeliOS嵌入式操作系统(OS)。HeliOS是一个功能齐全的操作系统࿰…...
mysql 数据库迁移到达梦数据库
1.windows安装达梦数据库,去官网下载 dm8 进行安装,安装后,可以使用管理工具管理数据 使用迁移工具对数据进行迁移; 2.使用php 或者 thinkphp连接达梦数据库 2.1、先PHP开启DM扩展 从达梦数据库安装目录下drivers/php_pdo 复制对…...
Java中的异常处理机制
今天想和大家探讨Java中的异常处理机制。异常处理是任何编程语言中不可或缺的一部分,它帮助我们处理程序运行时可能出现的错误,确保程序的健壮性和稳定性。Java作为一种强类型、面向对象的编程语言,提供了一套完整的异常处理框架。 1. 异常的…...
iOS 苹果开发者账号: 查看和添加设备UUID 及设备数量
参考链接:苹果开发者账号下添加新设备UUID - 简书 如果要添加新设备到 Profiles 证书里: 1.登录开发者中心 Sign In - Apple 2.找到证书设置: Certificate,Identifiers&Profiles > Profiles > 选择对应证书 edit &g…...
数据仓库工具箱—读书笔记02(Kimball维度建模技术概述03、维度表技术基础)
Kimball维度建模技术概述 记录一下读《数据仓库工具箱》时的思考,摘录一些书中关于维度建模比较重要的思想与大家分享🤣🤣🤣 第二章前言部分作者提到:技术的介绍应该通过涵盖各种行业的熟悉的用例展开(赞同…...
Linux中常用的Shell脚本(运维+常用)汇总
废话不多说,直接上干货! 一、运维脚本 (1)监控CPU和内存的使用情况 #!/bin/bashcpu_threshold80 mem_threshold80# 获取CPU和内存使用率 cpu_usage$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.…...
Java 方法注释:规范、实用和高质量的写法
目录 为什么要注释方法? 方法注释的基本要求 Javadoc 注释格式 示例:一个计算圆面积的方法 代码示例 注释分析 如何写出高质量的 Java 方法注释? 1. 关注可读性 2. 使用 Javadoc 格式 3. 描述异常 4. 适当的解释复杂的算法 5. 避…...
解决JIRA、Confluence用户自动注销、反复登录的问题
一、问题描述:当工作从从confluence里面打开jira的时候,在回到confluence时候,就自动退出了,需要账号密码登录重复登录,使人十分厌恶。 二、原因分析: 访问 JIRA、Confluence 或任何其他具有相同域或 IP 上…...
Python9-作业2
记录python学习,直到学会基本的爬虫,使用python搭建接口自动化测试就算学会了,在进阶webui自动化,app自动化 python基础8-灵活运用顺序、选择、循环结构 作业2九九乘法表三种方式打印九九乘法表使用两个嵌套循环使用列表推导式和…...
基于c语言的union、字符串、格式化输入输出
结构体之共用体union 共用体也叫联合体,其关键词为union 与结构体不同的是,共用体所开辟的存储空间仅仅为其中最长类型变量的存储空间而不是全部变量的存储空间,由于同一内存单元在同一时间内只能存放其中一种的数据类型,因此在每…...
SpringCloudAlibaba实战入门之路由网关Gateway初体验(十)
Spring Cloud 原先整合 Zuul 作为网关组件,Zuul 由 Netflix 公司提供的,现在已经不维护了。后面 Netflix 公司又出来了一个 Zuul2.0 网关,但由于一直没有发布稳定版本,所以 Spring Cloud 等不及了就自己推出一个网关,已…...
活着就好20241227
亲爱的朋友们,大家早上好!🌞 今天是27号,星期五,2024年12月的第二十七天,同时也是第51周的第五天,农历甲辰[龙]年十一月初二十三日。在这晨光渐浓的美好时刻,愿那温暖而明媚的阳光洒…...
robotframework中的测试套件
一. 简介 本文简单来了解一下,robotframework中的测试套件。 二. robotframework中测试套件 1. 什么是测试套件? 测试套件(Test Suite) 是一组相关测试用例的集合。每个测试套件通常代表一个特定的功能模块、系统组件或业务流程…...
Echarts连接数据库,实时绘制图表详解
文章目录 Echarts连接数据库,实时绘制图表详解一、引言二、步骤一:环境准备与数据库连接1、环境搭建2、数据库连接 三、步骤二:数据获取与处理1、查询数据库2、数据处理 四、步骤三:ECharts图表配置与渲染1、配置ECharts选项2、动…...
【QED】爱丽丝与混沌的无尽海
文章目录 题目题目描述输入输出格式数据范围测试样例 思路代码复杂度分析时间复杂度空间复杂度 题目 题目链接🔗 题目描述 如图所示,爱丽丝在一个3x3的迷宫之中,每个方格中标有 1 − 9 1-9 1−9各不相同的数字,爱丽丝可以从一格…...
CHM助手 >> 如何安装CHM助手
1 如何安装CHM助手 下载CHM助手.ezip,下载地址打开EverEdit,选择主菜单“扩展 -> 扩展管理 -> 从本地文件安装扩展”,在弹出的文件浏览窗口中选择插件安装包,如下图所示: 🕮说明: …...
硬件设计:LVDS电平标准
什么是LVDS? LVDS(Low-Voltage Differential Signaling)是一种高速、低功耗的差分信号传输标准。它通过一对差分信号线(通常是两根互补信号线)来传输数据,广泛应用于高速数字通信领域。 LVDS 的核心特点 低…...
宝塔-firefox(Docker应用)-构建自己的Web浏览器
安装基础软件 宝塔中安装firefox(Docker应用) 。宝塔中需要先安装docker及docker-composefirefox配置安装 点击firefox应用,选择【安装配置】点击右边绿色按钮,进行安装,这一步等待docker-compose根据你的配置初始化docker应用 等待安装 …...
微信小程序-基于Vant Weapp UI 组件库的Area 省市区选择
Area 省市区选择,省市区选择组件通常与 弹出层 组件配合使用。 areaList 格式 areaList 为对象结构,包含 province_list、city_list、county_list 三个 key。 每项以地区码作为 key,省市区名字作为 value。地区码为 6 位数字,前两…...
宏转录组+HiFi宏基因组:揭示厌氧消化中的碳流和能量转换
厌氧消化是一种重要的工程生物技术,对有机废物的资源回收和可再生能源的生产起着关键作用。然而,由于对未培养的厌氧菌及其适应环境变化的能力了解有限,这限制了该技术的优化和生物气生产的可持续性。今天小编带大家看一篇发表在《Microbiome…...
【VSCode】工作区及设置
【VSCode】工作区及设置 VSCode介绍工作区设置 VSCode介绍 Visual Studio Code(简称VSCode)是一个由微软开发的免费、开源的代码编辑器,以下是VSCode的一些功能及特性: 编辑器核心: 多文档界面:VSCode允许…...
瀚高数据库
文章目录 瀚高数据库安装瀚高数据库快速入门遇到的问题总结 瀚高数据库 瀚高数据库(HanGaoDB)是一款在分布式存储、高并发处理和高可用性方面表现优异的数据库,特别适用于大数据、高吞吐量、高并发的应用场景。它结合了传统 SQL 数据库和分布…...
xterm遇到的问题及解决方案
xterm遇到的问题及解决方案 /r插入终端导致的之后插入的数据覆盖了改行头部的数据 问题说明 如图所示,当在一行输入的候,输入的l插入到了改行的头部。 查看ws返回数据 可见ws返回的信息存在\r字符,在xterm.js中\r是回车字符的意思&…...
嵌入式单片机温湿度模块控制与实现
温湿度模块的使用 温湿度模块的特点 温湿度模块的原理通信的开始(打电话) 通信的过程(交流中)...
表达式语句、复合语句和空语句
欢迎拜访:雾里看山-CSDN博客 本篇主题:表达式语句、复合语句和空语句 发布时间:2024.12.26 隶属专栏:C语言 目录 1. 表达式语句定义作用常见类型赋值语句函数调用语句 2. 复合语句定义作用变量作用域 3. 空语句定义作用 1. 表达式…...
Dilateformer实战:使用Dilateformer实现图像分类任务(二)
文章目录 训练部分导入项目使用的库设置随机因子设置全局参数图像预处理与增强读取数据设置Loss设置模型设置优化器和学习率调整策略设置混合精度,DP多卡,EMA定义训练和验证函数训练函数验证函数调用训练和验证方法 运行以及结果查看测试完整的代码 在上…...
Kubernetes 镜像拉取策略全解析:如何根据需求选择最佳配置?
在Kubernetes集群里,拉取容器镜像是一个非常关键的步骤。这些镜像包含了应用程序及其所有需要的依赖项,Kubernetes通过拉取这些镜像来启动Pod中的容器。为了提升集群的稳定性、速度和安全性,Kubernetes提供了几种不同的镜像拉取策略。这篇文章…...
上海AI中心记录
1、js事件循环 调用栈(Call Stack): JavaScript 是单线程的,所有的代码执行都是在调用栈中进行的。当函数被调用时,进入栈中;执行完毕后,从栈中弹出。 任务队列(Task Queueÿ…...
oscp学习之路,Kioptix Level2靶场通关教程
oscp学习之路,Kioptix Level2靶场通关教程 靶场下载:Kioptrix Level 2.zip 链接: https://pan.baidu.com/s/1gxVRhrzLW1oI_MhcfWPn0w?pwd1111 提取码: 1111 搭建好靶场之后输入ip a看一下攻击机的IP。 确定好本机IP后,使用nmap扫描网段&…...
基于SpringBoot的蜗牛兼职网的设计与实现
一、项目背景 随着社会的快速发展,计算机的影响是全面且深入的。人们生活水平的不断提高,日常生活中人们对蜗牛兼职网方面的要求也在不断提高,需要兼职工作的人数更是不断增加,使得蜗牛兼职网的开发成为必需而且紧迫的事情。蜗牛…...
C++软件设计模式之装饰器模式
装饰器模式(Decorator Pattern)是C软件设计模式中的一种结构型设计模式,主要用于解决在不改变现有对象结构的情况下动态地给对象添加新功能的问题。通过使用装饰器模式,可以在运行时为对象添加新的行为,而不需要修改其…...
Spring Boot项目接收前端参数的11种方式
大家好,我是袁庭新。在前后端项目交互中,前端传递的数据可以通过HTTP请求发送到后端, 后端在Spring Boot中如何接收各种复杂的前端数据呢?这篇文章总结了11种在Spring Boot中接收前端数据的方式。 1 搭建项目 1.通过Spring Init…...
通过GRE协议组建VPN网络
GRE(Generic Routing Encapsulation,通用路由封装协议)协议是一种简单而有效的封装协议,它在网络中的广泛应用,比如在构建VPN网络。 GRE是一种封装协议,它允许网络层协议(如IP)的…...
you-get使用cookies下载B站视频
B站视频更换BV号以后,使用you-get不能下载了。 首先更新你的you-get pip install --upgrade you-get 更新完成后再次使用you-get -u 命令会显示使用cookies才能下载更多清晰度的视频 使用Edge浏览器,添加插件 Cookie-Editor 点击上图的导出按钮&am…...
使用Excel制作通达信自定义“序列数据“
序列数据的视频教程演示 Excel制作通达信自定义序列数据 1.序列数据的制作方法:删掉没有用的数据(行与列)和股代码格式处理,是和外部数据的制作方法是相同,自己上面看历史博文。只需要判断一下,股代码跟随的…...
基于 Nginx 的网站服务器与 LNMP 平台搭建指南
一,Nginx概述 (一)Nginx的作用 Nginx在网络服务器架构中扮演着多面的角色。其初始设定专注于静态网络数据的处理,能高效地为用户提供诸如HTML,CSS,JavaScript等静态资源。当面对动态数据时,借助php - fpm模块,Nginx能够解析php源代码,实现动态页面的生成与展示。在处理…...
OpenCV计算机视觉 03 椒盐噪声的添加与常见的平滑处理方式(均值、方框、高斯、中值)
上一篇文章:OpenCV计算机视觉 02 图片修改 图像运算 边缘填充 阈值处理 添加椒盐噪声 def add_peppersalt_noise(image, n10000):result image.copy()h, w image.shape[:2] # 获取图片的高和宽for i in range(n): # 生成n个椒盐噪声x np.random.randint(…...
WPF自定义窗口 输入验证不生效
WPF自定义窗口 输入验证不生效 WPF ValidationRule 不生效 WPF ValidationRule 不生效 解决方案:在WindowStyle的Template中添加AdornerDecorator标签。 <Style x:Key"WindowStyle1" TargetType"{x:Type Window}"><Setter Property&…...
【MySQL】 SQL优化讲解
一、优化前的思考 在定位到慢查询后,面试官常问如何优化或分析慢查询的SQL语句。若存在聚合查询、多表查询,可尝试优化SQL语句结构,如多表查询可新增临时表;若表数据量过大,可添加索引,但添加索引后仍慢则…...