最全面的数据库健康检查报告模板
ccwgpt 2024-12-27 15:51 105 浏览 0 评论
XXX系统数据库健康检查报告
创建日期：2020年7月10日
巡检摘要
日期 | 巡检人 | 备注 |
2020-07-10 | xxx | |
巡检项：
| ||
目录
1 概要 4
2 系统配置检查 4
2.1 操作系统版本及补丁 4
2.2 网卡信息 5
2.3 系统IP规划 5
2.4 硬盘空间及利用率 6
2.5 系统负载状态 6
2.6 系统日志 6
3 数据库配置检查 7
3.1 数据库概况 7
3.2 数据库参数 7
3.3 运行日志和跟踪文件 9
3.4 数据库无效对象 10
3.5 SYSTEM系统表空间 10
3.6 控制文件 10
3.7 日志文件 11
3.8 数据文件 11
3.9 数据库归档 12
3.10 表空间 12
3.11 集群状态 13
3.12 ASM空间情况 14
3.13 数据库高可用feature 15
3.14 Dataguard 同步 15
4 数据库性能（AWR均节选业务高峰时段） 16
4.1 Instance Efficiency Percentages (Target 100%) 16
4.2 数据库资源使用情况 16
4.3 Top 10 Foreground Events by Total Wait Time 17
5 影响较大的SQL语句: 17
5.1 SQL调整原则 17
5.2 SQL ordered by Elapsed Time 18
5.3 SQL ordered by CPU Time 20
5.4 SQL ordered by Gets 21
5.5 SQL ordered by Reads 23
5.6 SQL ordered by Parse Calls 23
6 数据库备份 24
7 问题总结与建议 25
7.1 无效对象 25
7.2 SQL建议 25
7.3 数据库后台日志 26
7.4 数据库性能 26
7.5 表空间 26
7.6 Dblink访问 26
7.7 数据库备份 26
7.8 网卡 27
7.9 其他 27
概要
本次巡检主要对电子病历系统oracle集群数据库的配置，运行状态，性能进行检查，同时也进行相关的操作系统配置检查，包括一定量的数据库性能评估工作。
系统配置检查
和数据库相关的操作系统配置将被检查，包括以下方面：
- 操作系统补丁
- 存放oracle 文件的硬盘区可用空间(oracle 文件包括：数据文件，控制文件，在线redo logs，归档redo logs，运行情况文件和跟踪文件)
- 硬盘利用率
- CPU利用率
(这部分的检查并不是针对操作系统或硬件的全面深入的检查，如有上述要求请与操作系统厂商联系)
操作系统版本及补丁
服务器名 | 服务器配置 | 系统版本 | 补丁推荐 |
rac1 | cpu/mem: 40cores/512GB | CentOS 6.9（64bit） | |
rac2 | cpu/mem: 40cores/512GB | CentOS 6.9（64bit） |
网卡信息
目前集群私有网卡是千兆网卡，私有网卡主要用于集群两个节点间的数据交互，数据流量会比较大，官方推荐万兆或者光纤交换机
系统IP规划
#####################Configure for RAC################################
#RAC1
192.168.3.31 rac1 rac1.oracle.com
192.168.3.131 rac1-vip
163.168.3.31 rac1-priv
#RAC2
192.168.3.32 rac2 rac2.oracle.com
192.168.3.132 rac2-vip
163.168.3.32 rac2-priv
#scan-ip
192.168.3.130 dzblrac-cluster dzblrac-cluster-scan
####################Configure for RAC################################
硬盘空间及利用率
硬盘可用情况如下示:
服务器 | 文件系统 | 总大小(GB) | 可用大小(GB) | 使用率 |
rac1 | / | 201GB | 117GB | 39% |
/tmp | 9.8GB | 9.2GB | 1% | |
/OracleBak | 1008GB | 922GB | 4% | |
rac2 | / | 201GB | 164G | 15% |
/tmp | 9.8GB | 9.2GB | 1% |
系统负载状态
系统配置：cpu=40 mem=512GB
rac1:
rac2:
目前系统压力很小
系统日志
Jul 5 20:09:41 rac1 Oracle GoldenGate Capture for Oracle[209807]: 2020-07-05 20:09:41 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, emrnew.prm: PROCESS ABENDING.
Jul 5 20:13:44 rac1 Oracle GoldenGate Capture for Oracle[212085]: 2020-07-05 20:13:44 ERROR OGG-00664 Oracle GoldenGate Capture for Oracle, emrnew.prm: OCI Error beginning session (status = 1089-ORA-01089: immediate shutdown in progress - no operations are permitted).
除了OGG相关报错， 未发现操作系统日志报错
数据库配置检查
本次检查工作主要针对电子病历EMR数据库。
数据库概况
数据库名 | 数据库版本 | 数据库字符集 | 数据库大小 |
ORCL | ORACLE 11.2.0.4 | ZHS16GBK | 58.4GB |
数据库参数
参数文件‘init.ora’包含了数据库配置参数，在数据库启动时被使用，列出了数据库所有的非默认值的参数。
init.ora Parameters
Parameter Name | Begin value | End value (if different) |
_ash_size | 104857600 | |
_serial_direct_read | NEVER | |
audit_file_dest | /u01/app/oracle/admin/dzblorcl/adump | |
audit_trail | DB | |
cluster_database | TRUE | |
compatible | 11.2.0.4.0 | |
control_files | +DATA/dzblorcl/controlfile/current.260.1042555203 | |
db_block_size | 8192 | |
db_create_file_dest | +DATA | |
db_domain | ||
db_files | 1000 | |
db_name | orcl | |
deferred_segment_creation | FALSE | |
diagnostic_dest | /u01/app/oracle | |
dispatchers | (PROTOCOL=TCP) (SERVICE=dzblorclXDB) | |
enable_goldengate_replication | TRUE | |
fal_client | dzblorcl | |
fal_server | dzblorcldg | |
instance_number | 1 | |
local_listener | (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.3.131)(PORT=1521)) | |
log_archive_config | DG_CONFIG=(orcl, orcldg) | |
log_archive_dest_1 | location=+FRA | |
log_archive_dest_2 | SERVICE=orcldg LGWR ASYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=orcldg | |
open_cursors | 1000 | |
parallel_force_local | TRUE | |
pga_aggregate_target | 53687091200 | |
plsql_warnings | DISABLE:ALL | |
processes | 5000 | |
remote_listener | dzblrac-cluster-scan:1521 | |
remote_login_passwordfile | EXCLUSIVE | |
service_names | ORCL | |
session_cached_cursors | 300 | |
sga_max_size | 161061273600 | |
sga_target | 161061273600 | |
spfile | +DATA/orcl/spfileorcl.ora | |
standby_file_management | AUTO | |
thread | 1 | |
undo_tablespace | UNDOTBS1 |
初始化建议参数都已经进行过调整
运行日志和跟踪文件
注意每天监控运行日志文件中的出错信息，以便于在问题还是隐患的时候及时发现并解决掉。建议每月初将当前的alert.log重新命名以作备份，同时也可以避免alert.log文件变得太大不易管理。
近3天出现错误日志：
TNS-12535: TNS:operation timed out
ns secondary err code: 12606
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.130.27)(PORT=51145))
WARNING: inbound connection timed out (ORA-3136)
Mon Jul 06 13:58:34 2020
ORA-3136 连接超时问题，表示client端在默认60秒内没有完成connection 认证报错，或者负载过高导致连接出现timeout. 一般来说应用没出现问题或者报错，可以优先忽略。如报错频繁影响应用程序，可以通过设置参数INBOUND_CONNECT_TIMEOUT=0，避免timeout现象。
参考：Note465043.1 Troubleshooting ORA - 3136WARNING Inbound Connection Timed Out
数据库无效对象
目前数据库有193个无效对象
SYSTEM系统表空间
业务用户supcon, comm有两个索引建在系统表空间system
控制文件
每个数据库至少有一个控制文件。控制文件记录了数据库的物理结构及同步信息。
Controlfile Name | Status |
+DATA/dzblorcl/controlfile/current.260.1042555203 | VALID |
+DATA/dzblorcl/controlfile/current.260.1042555203 | VALID |
日志文件
每个节点四组日志，每组1024MB
数据文件
数据库文件 /tmp/FY_REC_DATA.DAT， /tmp/FY_RST_DATA.DAT 目前被错误建在临时目录/tmp，数据文件一般都放在ASM磁盘组+DATA中。经确认目前这两个数据文件未被使用，以后也不会被使用。建议暂不进行处理。目前其他数据文件状态正常
数据库归档
Oracle允许将写满的在线Redo Log文件存放在一个或多个脱机位置，即归档Redo Log。在线日志文件通过归档写入归档日志文件。后台进程ARCn自动进行归档操作。您能通过归档日志进行：
- 在线备份
- 基于时间的恢复
Archived Redo Log Settings
DB NAME | Database log mode | Automatic archival | Archive Destination |
DZBLORCL | Archive Mode | YES | +FRA |
表空间
每个数据库由一个或多个逻辑存储单位，即表空间，所组成。而表空间则由逻辑存储单位段所组成。而段将被分为多个片。用户对象不应该在系统表空间中创建。这将导致系统表空间的碎片产生，并且阻止表空间增长。
目前数据库表空间使用率都不高，表空间使用率超过85%, 就要引起注意，需要添加数据文件。
集群状态
目前集群运行正常
ASM空间情况
ASM磁盘组空间使用较低
数据库高可用feature
db_name | force_logging | flashback_on | supplemental_log | recyclebin | dataguard |
dzblorcl | yes | no | yes | on | yes |
Dataguard 同步
Oracle dataguard 是官方推荐的一款数据库容灾产品，通过实时传输数据库redo log日志到standby端，并实时应用日志到standby, 实现数据库物理级别，数据库异地的数据同步，达到容灾的目的。
DATABASE_ROLE | DB_UNIQUE_NAME | OPEN_MODE | PROTECTION_LEVEL | SWITCHOVER_STATUS |
PHYSICAL STANDBY | dzblorcldg | READ ONLY WITH APPLY | MAXIMUM PERFORMANCE | NOT ALLOWED |
目前dataguard 处于实时数据恢复状态，实例已经Open可提供只读操作，已经和Primary实时同步。
数据库性能（AWR均节选业务高峰时段）
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | 100.00 | Redo NoWait %: | 100.00 |
Buffer Hit %: | 100.00 | In-memory Sort %: | 100.00 |
Library Hit %: | 99.24 | Soft Parse %: | 99.41 |
Execute to Parse %: | 56.52 | Latch Hit %: | 99.99 |
Parse CPU to Parse Elapsd %: | 60.18 | % Non-Parse CPU: | 98.57 |
数据库的各个指标的命中率正常，数据库压力不大。
数据库资源使用情况
CURRENT_UTILIZATION：当前在用的数目（资源、锁或进程）
MAX_UTILIZATION ：自最后一个实例启动以来这个资源的最大消耗I
LIMIT_VALUE：资源的限制值。
当前数据库主要会话数(processes)，进程数(sessions)，锁(dml_locks, ges_locks)等资源都未达到最大值。
Top 10 Foreground Events by Total Wait Time
Event | Waits | Total Wait Time (sec) | Wait Avg(ms) | % DB time | Wait Class |
DB CPU | 13.5K | 94.7 | |||
SQL*Net more data to client | 236,611 | 302.5 | 1 | 2.1 | Network |
SQL*Net message from dblink | 184,490 | 287.6 | 2 | 2.0 | Network |
control file sequential read | 586,524 | 144.6 | 0 | 1.0 | System I/O |
log file sync | 70,429 | 36.2 | 1 | .3 | Commit |
gc current block 2-way | 81,905 | 27.2 | 0 | .2 | Cluster |
gc cr block 2-way | 73,638 | 25.9 | 0 | .2 | Cluster |
rdbms ipc reply | 82,800 | 17.1 | 0 | .1 | Other |
gc current grant busy | 40,543 | 12.5 | 0 | .1 | Cluster |
log file sequential read | 38,577 | 10.2 | 0 | .1 | System I/O |
等待DB CPU， 可以忽略，是数据库正常等待
Wait class里Network相关的等待比较严重， 如SQL*Net message from dblink 等待比较严重，和数据库大量使用dblink有关。
其他等待在当前时间段，不严重，对数据库影响很小，可以忽略。
影响较大的SQL语句:
SQL调整原则
SQL语句性能调整的目标是：
去掉不必要的大表全表扫描 不必要的大表全表扫描会造成不必要的输入输出，而且还会拖垮整个数据库；
检查优化索引的使用 这对于提高查询速度来说非常重要；
检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重写；
调整PCTFREE和PCTUSED等存储参数优化插入、更新或者删除等操作；
考虑数据表的全表扫描和在多个CPU的情况下考虑并行查询;
SQL ordered by Elapsed Time
Elapsed Time (s) | Executions | Elapsed Time per Exec (s) | %Total | %CPU | %IO | SQL Id | SQL Module | SQL Text |
2,496.56 | 0 | 17.57 | 99.61 | 0.00 | 95g2k0gx77y09 | iawork@rac1 (TNS V1-V3) | SELECT a.INST_ID, a.Sid, c.Ser... | |
792.01 | 825 | 0.96 | 5.57 | 99.56 | 0.00 | 99dd1032rfbpw | w3wp.exe | DELETE FROM CPOE_TEST_RESULT W... |
654.05 | 626 | 1.04 | 4.60 | 99.65 | 0.00 | a2z578h5vqtr3 | Unicorn.exe | SELECT PATIENT_ID, PATIENT_NAM... |
516.47 | 739 | 0.70 | 3.63 | 99.37 | 0.00 | 8xn7jp79ywh1g | JDBC Thin Client | SELECT a.*, e.id as e_id, e.ex... |
489.24 | 437 | 1.12 | 3.44 | 99.59 | 0.00 | asvqf4vfrbaj9 | ExecSQLTool.exe | Select b.result_item_code As i... |
444.69 | 185 | 2.40 | 3.13 | 34.71 | 0.00 | 3c6x3ajfk4cn2 | ORACLE.EXE | SELECT /*+ OPAQUE_TRANSFORM */... |
372.67 | 360 | 1.04 | 2.62 | 99.68 | 0.00 | 25v7fu812tf4b | oracle@hisdb2 (TNS V1-V3) | SELECT "PAT_INPATIENTNO", "PAT... |
247.58 | 750 | 0.33 | 1.74 | 98.73 | 0.00 | dc30xnqmjvmb7 | JDBC Thin Client | SELECT id, report_id, request_... |
195.95 | 277 | 0.71 | 1.38 | 90.39 | 0.00 | 9vthrjwcr06wq | w3wp.exe | SELECT M.CLINIC_ITEM_NAME, M.?ú... |
194.20 | 1,647 | 0.12 | 1.37 | 99.10 | 0.00 | 110axn1tv1ssw | w3wp.exe | SELECT ORDER_CHECK_NO FROM ORD... |
191.62 | 1,696 | 0.11 | 1.35 | 99.07 | 0.00 | 5cyxmk7sa9ndb | w3wp.exe | SELECT T.ORDER_CHECK_NO FROM O... |
176.13 | 1,658 | 0.11 | 1.24 | 99.03 | 0.00 | bmt7htt8w9k9z | w3wp.exe | INSERT INTO ORDADM.CPOE_ORDER_... |
175.22 | 1,662 | 0.11 | 1.23 | 99.24 | 0.00 | 4qnqpz7jb46uh | w3wp.exe | SELECT MAX(ORDER_CHECK_NO) FRO... |
156.91 | 552 | 0.28 | 1.10 | 99.56 | 0.00 | 395qaxvcycb64 | w3wp.exe | select * from CPOE_OUTP_ORDERS... |
SQL ordered by elapsed Time：记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。
- TOP 1 SQL: 95g2k0gx77y09，消耗时间比较长， 数据库用户iawork, SQL内容:
SELECT a.INST_ID, a.Sid, c.Serial#, v.Spid, Decode(a.TYPE, 'TM', B1.NAME, '') obj, v.PROGRAM process_program, c.MACHINE, c.MODULE, c.PROGRAM session_program, c.Status, c.Username, c.Command, c.ACTION, c.Logon_Time, a.CTIME, a.TYPE, decode(a.lmode, 0, 'None', 1, 'Null', 2, 'Row share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6, 'Exclusive') lock_mode, decode(a.request, 0, 'None', 1, 'Null', 2, 'Row share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6, 'Exclusive') request_mode, a.BLOCK FROM Gv$lock a, Sys.Obj$ B1, Sys.User$ B2, Gv$session c, Gv$process v WHERE a.Id1 = B1.Obj#(+) AND B1.Owner# = B2.User#(+) AND a.Sid = c.Sid AND c.TYPE = 'USER' AND v.Addr = c.Paddr AND c.Inst_Id = v.Inst_Id AND A.INST_ID=C.INST_ID AND a.TYPE = 'TM' order by c.LOGON_TIME |
从SQL的内容来看，在查询当期会话信息
- 执行时间超过2秒的SQL： 3c6x3ajfk4cn2
SELECT /*+ OPAQUE_TRANSFORM */ "PACS_NO", "PATIENT_ID", "EVENT_NO", "PATIENT_TYPE", "PACS_TYPE", "PATIENT_NAME", "PATIENT_SEX", "PATIENT_AGE", "IN_DEPT", "BED", "WARD", "ADDRESS", "TELEPHONE", "MARRIAGE", "PROFESSION", "CHECKNO", "BARCODE_ID", "INSPECT_TYPE", "INSPECT_SUB_TYPE", "INSPECT_NAME", "INSTRUMENT_NAME", "APPLICANT", "OPERATER", "INSPECTOR", "OPERATER_TIME", "REPORT_TIME", "LAST_MODIFY_TIME", "MODIFY_FLAG", "REMARK1", "REMARK2", "STATUS", "CONCLUSION", "IMAGING" FROM "ZEMR_PACS_REPORT" "T" WHERE ("IMAGING" IS NOT NULL OR "CONCLUSION" IS NOT NULL) AND "REPORT_TIME">TRUNC(:1-10) | |
以下是执行计划：
ZEMR_PACS_REPORT 是一个比较复杂的视图，从执行计划来看，扫描成本较高的表有: CPOE_OUTP_ORDERS和CPOE_EXAM_DETAIL，同时走了全表扫描，扫描了1236k行和368k行数据，导致SQL超过2秒以上，具有了解具体的业务进一步优化。
其他SQL消耗时间都整体不长。
SQL ordered by CPU Time
CPU Time (s) | Executions | CPU per Exec (s) | %Total | Elapsed Time (s) | %CPU | %IO | SQL Id | SQL Module | SQL Text |
2,486.87 | 0 | 18.47 | 2,496.56 | 99.61 | 0.00 | 95g2k0gx77y09 | iawork@rac1 (TNS V1-V3) | SELECT a.INST_ID, a.Sid, c.Ser... | |
788.51 | 825 | 0.96 | 5.86 | 792.01 | 99.56 | 0.00 | 99dd1032rfbpw | w3wp.exe | DELETE FROM CPOE_TEST_RESULT W... |
651.77 | 626 | 1.04 | 4.84 | 654.05 | 99.65 | 0.00 | a2z578h5vqtr3 | Unicorn.exe | SELECT PATIENT_ID, PATIENT_NAM... |
513.23 | 739 | 0.69 | 3.81 | 516.47 | 99.37 | 0.00 | 8xn7jp79ywh1g | JDBC Thin Client | SELECT a.*, e.id as e_id, e.ex... |
487.23 | 437 | 1.11 | 3.62 | 489.24 | 99.59 | 0.00 | asvqf4vfrbaj9 | ExecSQLTool.exe | Select b.result_item_code As i... |
371.48 | 360 | 1.03 | 2.76 | 372.67 | 99.68 | 0.00 | 25v7fu812tf4b | oracle@hisdb2 (TNS V1-V3) | SELECT "PAT_INPATIENTNO", "PAT... |
244.44 | 750 | 0.33 | 1.82 | 247.58 | 98.73 | 0.00 | dc30xnqmjvmb7 | JDBC Thin Client | SELECT id, report_id, request_... |
192.46 | 1,647 | 0.12 | 1.43 | 194.20 | 99.10 | 0.00 | 110axn1tv1ssw | w3wp.exe | SELECT ORDER_CHECK_NO FROM ORD... |
189.85 | 1,696 | 0.11 | 1.41 | 191.62 | 99.07 | 0.00 | 5cyxmk7sa9ndb | w3wp.exe | SELECT T.ORDER_CHECK_NO FROM O... |
177.12 | 277 | 0.64 | 1.32 | 195.95 | 90.39 | 0.00 | 9vthrjwcr06wq | w3wp.exe | SELECT M.CLINIC_ITEM_NAME, M.?ú... |
174.43 | 1,658 | 0.11 | 1.30 | 176.13 | 99.03 | 0.00 | bmt7htt8w9k9z | w3wp.exe | INSERT INTO ORDADM.CPOE_ORDER_... |
173.88 | 1,662 | 0.10 | 1.29 | 175.22 | 99.24 | 0.00 | 4qnqpz7jb46uh | w3wp.exe | SELECT MAX(ORDER_CHECK_NO) FRO... |
156.23 | 552 | 0.28 | 1.16 | 156.91 | 99.56 | 0.00 | 395qaxvcycb64 | w3wp.exe | select * from CPOE_OUTP_ORDERS... |
154.35 | 185 | 0.83 | 1.15 | 444.69 | 34.71 | 0.00 | 3c6x3ajfk4cn2 | ORACLE.EXE | SELECT /*+ OPAQUE_TRANSFORM */... |
SQL ordered by CPU time: 记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)
CPU的资源消耗上，还是同样的SQL : 95g2k0gx77y09,
SQL ordered by Gets
Buffer Gets | Executions | Gets per Exec | %Total | Elapsed Time (s) | %CPU | %IO | SQL Id | SQL Module | SQL Text |
254,805,414 | 360 | 707,792.82 | 15.66 | 372.67 | 99.7 | 0 | 25v7fu812tf4b | oracle@hisdb2 (TNS V1-V3) | SELECT "PAT_INPATIENTNO", "PAT... |
77,112,750 | 739 | 104,347.43 | 4.74 | 516.47 | 99.4 | 0 | 8xn7jp79ywh1g | JDBC Thin Client | SELECT a.*, e.id as e_id, e.ex... |
47,829,036 | 437 | 109,448.59 | 2.94 | 489.24 | 99.6 | 0 | asvqf4vfrbaj9 | ExecSQLTool.exe | Select b.result_item_code As i... |
45,674,399 | 750 | 60,899.20 | 2.81 | 247.58 | 98.7 | 0 | dc30xnqmjvmb7 | JDBC Thin Client | SELECT id, report_id, request_... |
40,289,848 | 0 | 2.48 | 79.77 | 99.4 | 0 | c8dx985h4zwca | oracle@ods-server (TNS V1-V3) | SELECT "A1"."PATIENTCHARGE_ID"... | |
37,902,751 | 1,696 | 22,348.32 | 2.33 | 191.62 | 99.1 | 0 | 5cyxmk7sa9ndb | w3wp.exe | SELECT T.ORDER_CHECK_NO FROM O... |
37,142,877 | 1,662 | 22,348.30 | 2.28 | 175.22 | 99.2 | 0 | 4qnqpz7jb46uh | w3wp.exe | SELECT MAX(ORDER_CHECK_NO) FRO... |
37,061,741 | 1,658 | 22,353.28 | 2.28 | 176.13 | 99 | 0 | bmt7htt8w9k9z | w3wp.exe | INSERT INTO ORDADM.CPOE_ORDER_... |
36,807,682 | 1,647 | 22,348.32 | 2.26 | 194.20 | 99.1 | 0 | 110axn1tv1ssw | w3wp.exe | SELECT ORDER_CHECK_NO FROM ORD... |
31,189,110 | 44 | 708,843.41 | 1.92 | 43.77 | 99.7 | 0 | 48ynbdm8nck7b | oracle@hisdb2 (TNS V1-V3) | SELECT "PAT_INPATIENTNO", "PAT... |
30,899,994 | 552 | 55,978.25 | 1.90 | 156.91 | 99.6 | 0 | 395qaxvcycb64 | w3wp.exe | select * from CPOE_OUTP_ORDERS... |
29,299,299 | 212 | 138,204.24 | 1.80 | 131.25 | 98.1 | 0 | dvd3fhv94zsrk | w3wp.exe | select * from v_drug_stock a w... |
25,271,933 | 185 | 136,605.04 | 1.55 | 444.69 | 34.7 | 0 | 3c6x3ajfk4cn2 | ORACLE.EXE | SELECT /*+ OPAQUE_TRANSFORM */... |
19,077,381 | 825 | 23,124.10 | 1.17 | 792.01 | 99.6 | 0 | 99dd1032rfbpw | w3wp.exe | DELETE FROM CPOE_TEST_RESULT W... |
17,575,285 | 161 | 109,163.26 | 1.08 | 104.83 | 99.1 | 0 | 5wgasuumx8mts | DDTEK ODBC Oracle | select VERSION_NO as VERSION_... |
17,385,747 | 277 | 62,764.43 | 1.07 | 195.95 | 90.4 | 0 | 9vthrjwcr06wq | w3wp.exe | SELECT M.CLINIC_ITEM_NAME, M.?ú... |
SQL ordered by Gets：记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)
目前这项指标正常
SQL ordered by Reads
Physical Reads | Executions | Reads per Exec | %Total | Elapsed Time (s) | %CPU | %IO | SQL Id | SQL Module | SQL Text |
121 | 9,004 | 0.01 | 0.58 | 1.99 | 41.25 | 1.02 | 9397yzqdrz2gv | oracle@hisdb2 (TNS V1-V3) | UPDATE "T_YIHUI_RESI_FEE" "A1"... |
33 | 0 | 0.16 | 79.77 | 99.43 | 0.02 | c8dx985h4zwca | oracle@ods-server (TNS V1-V3) | SELECT "A1"."PATIENTCHARGE_ID"... | |
16 | 33 | 0.48 | 0.08 | 0.06 | 62.49 | 4.35 | 508zw0x4na640 | Unicorn.exe | INSERT ALL INTO DOC_CLINIC_DAT... |
9 | 14,453 | 0.00 | 0.04 | 3.20 | 29.25 | 0.10 | 7jvcnbkgppx7b | w3wp.exe | INSERT INTO CPOE_TEST_RESULT (... |
5 | 191 | 0.03 | 0.02 | 27.63 | 98.11 | 0.03 | 4vpuqx31nvaru | w3wp.exe | select distinct t2.patient_con... |
5 | 358 | 0.01 | 0.02 | 64.22 | 96.80 | 0.00 | g7hc815q7vnuu | w3wp.exe | insert into CPOE_ORDER_SEND (O... |
3 | 825 | 0.00 | 0.01 | 792.01 | 99.56 | 0.00 | 99dd1032rfbpw | w3wp.exe | DELETE FROM CPOE_TEST_RESULT W... |
2 | 277 | 0.01 | 0.01 | 195.95 | 90.39 | 0.00 | 9vthrjwcr06wq | w3wp.exe | SELECT M.CLINIC_ITEM_NAME, M.?ú... |
2 | 16 | 0.13 | 0.01 | 0.06 | 69.27 | 1.38 | fhqs73k033qzd | Unicorn.exe | INSERT ALL INTO DOC_CLINIC_ITE... |
1 | 268 | 0.00 | 0.00 | 36.57 | 98.46 | 0.01 | 33hkfuds8puuu | w3wp.exe | select * from (SELECT A.PATIEN... |
SQL ordered by Reads: 记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)，可以反映具体某些SQL执行效率，一般都推荐从内存读取，物理读一般都指从硬盘读取数据，效率较低， delete，update, insert都会带来物理读，这是不可避免的。
目前数据库 除了top 1的update sql，其他的物理读都不高。
SQL ordered by Parse Calls
Parse Calls | Executions | % Total Parses | SQL Id | SQL Module | SQL Text |
497,125 | 497,119 | 20.19 | ggwdfnuqjg9xy | w3wp.exe | SELECT COUNT(1) FROM PATS_IN_H... |
289,729 | 289,730 | 11.77 | 3bcxa2bxgu6a2 | w3wp.exe | SELECT M.PATIENT_ID, M.VISIT_I... |
289,334 | 289,333 | 11.75 | 1b6f97pwy7az2 | w3wp.exe | SELECT PATIENT_ID, VISIT_ID, A... |
113,276 | 113,276 | 4.60 | 7h35uxf5uhmm1 | w3wp.exe | select sysdate from dual |
106,042 | 106,042 | 4.31 | djnrjdzdb65rd | w3wp.exe | SELECT ORDER_NO, PAT_ID, VISIT... |
76,202 | 76,202 | 3.10 | fuphg1dmwa2js | w3wp.exe | SELECT COUNT(1) FROM cpoe_orde... |
71,169 | 71,169 | 2.89 | caba6r6j8mthj | w3wp.exe | SELECT a.order_no, a.ord_statu... |
53,517 | 53,517 | 2.17 | 9q9yhgc0u15gk | w3wp.exe | insert into CPOE_ORDER_EXE_REC... |
33,385 | 33,385 | 1.36 | gcf937cx27gsy | w3wp.exe | SELECT ORDER_NO, PAT_ID, VISIT... |
25,378 | 25,378 | 1.03 | 6ynn15u2kycjw | w3wp.exe | SELECT VERSION, PACKAGE_PATH F... |
SQL ordered by Parse Calls: 即记录了SQL的软解析次数的TOP SQL， 软解析一般SQL通过绑定变量的形式执行。在Oracle的SQL优化引擎中推荐通过绑定变量的形式执行SQL，执行效率高。
目前这项指标正常
数据库备份
备份策略：每天晚上22:50进行数据库RMAN全备。
50 22 * * * sh /opt/scripts/rmanfull.sh
每天全量压缩备份，容量15GB左右，查看备份情况如下：（备份正常）
备份状态正常，目前归档没有进行备份，建议把归档放到每天的备份任务中。
问题总结与建议
无效对象
目前数据库存在大量无效对象，存储过程，视图等，建议开发仔细确认哪些对象是否需要，不需要的对象进行删除，生产环境严格禁止有测试对象存在。
SQL建议
- 以下iawork 用户下SQL占用CPU较高，目前整体对性能影响不算大，其他SQL整体运行速度良好，后期需要进行观察
SELECT a.INST_ID, a.Sid, c.Serial#, v.Spid, Decode(a.TYPE, 'TM', B1.NAME, '') obj, v.PROGRAM process_program, c.MACHINE, c.MODULE, c.PROGRAM session_program, c.Status, c.Username, c.Command, c.ACTION, c.Logon_Time, a.CTIME, a.TYPE, decode(a.lmode, 0, 'None', 1, 'Null', 2, 'Row share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6, 'Exclusive') lock_mode, decode(a.request, 0, 'None', 1, 'Null', 2, 'Row share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6, 'Exclusive') request_mode, a.BLOCK FROM Gv$lock a, Sys.Obj$ B1, Sys.User$ B2, Gv$session c, Gv$process v WHERE a.Id1 = B1.Obj#(+) AND B1.Owner# = B2.User#(+) AND a.Sid = c.Sid AND c.TYPE = 'USER' AND v.Addr = c.Paddr AND c.Inst_Id = v.Inst_Id AND A.INST_ID=C.INST_ID AND a.TYPE = 'TM' order by c.LOGON_TIME |
- 视图ZEMR_PACS_REPORT查询耗时超过2秒，视图里大表走了全表扫描，需要进一步优化SQL或者添加索引，进行相关优化。 参考 5.2
数据库后台日志
后台出现ORA-3136 连接超时报错，，表示client端在默认60秒内没有完成connection 认证报错，或者负载过高导致连接出现timeout. 一般来说应用没出现问题或者报错，可以优先忽略。如报错频繁影响应用程序，可以通过设置参数INBOUND_CONNECT_TIMEOUT=0，避免timeout现象。
数据库性能
目前数据库各项性能指标正常，配置参数都做过优化，数据库的资源都未达到最大值。随着业务量，数据量增加，数据库需要持续进行巡检，优化。
表空间
发现业务表的索引建在了系统system表空间，建议统一移到各自用户表空间下。参考 3.10
Dblink访问
数据库使用大量dblink， 目前发现有些访问是跨网段访问，硬件交换机没有进行多层转换，确保网络层网络延迟低，速度快。参考 4.3 数据库等待事件。
数据库备份
- 目前备份只有RMAN基于时间点恢复的备份，建议加上逻辑备份datapump，可以进行容灾快速恢复。
- 当前备份策略是两天进行一次全备，后续数据库体量大了以后，耗时较长，影响业务，建议进行增量备份。
网卡
目前集群私有网卡是千兆网卡，建议采用万兆活光纤网网络，可以有效提供集群节点间的数据通信，提高数据库集群性能。
其他
目前中间件Oracle Goldengate 部署在节点1， 数据库已经部署了Oracle Dataguard，建议Goldengate迁移到Dataguard端，减少对主库的影响。
相关推荐
- 一个基于.Net Core遵循Clean Architecture原则开源架构
-
今天给大家推荐一个遵循CleanArchitecture原则开源架构。项目简介这是基于Asp.netCore6开发的，遵循CleanArchitecture原则，可以高效、快速地构建基于Ra...
- AI写代码翻车无数次，我发现只要提前做好这3步，bug立减80%
-
写十万行全是bug之后终于找到方法了开发"提示词管理助手"新版本那会儿，我差点被bug整崩溃。刚开始两周，全靠AI改代码架构，结果十万行程序漏洞百出。本来以为AI说没问题就稳了，结果...
- OneCode低代码平台的事件驱动设计:架构解析与实践
-
引言：低代码平台的事件驱动范式在现代软件开发中，事件驱动架构（EDA）已成为构建灵活、松耦合系统的核心范式。OneCode低代码平台通过创新性的注解驱动设计，将事件驱动理念深度融入平台架构，实现了业务...
- 国内大厂AI插件评测:根据UI图生成Vue前端代码
-
在IDEA中安装大厂的AI插件，打开ruoyi增强项目：yudao-ui-admin-vue31.CodeBuddy插件登录腾讯的CodeBuddy后，大模型选择deepseek-v3，输入提示语：...
- AI+低代码技术揭秘(二):核心架构
-
本文档介绍了为VTJ低代码平台提供支持的基本架构组件，包括Engine编排层、Provider服务系统、数据模型和代码生成管道。有关UI组件库和widget系统的信息，请参阅UI...
- GitDiagram用AI把代码库变成可视化架构图
-
这是一个名为gitdiagram的开源工具，可将GitHub仓库实时转换为交互式架构图，帮助开发者快速理解代码结构。核心功能一键可视化：替换GitHubURL中的"hub...
- 30天自制操作系统:第六天:代码架构整理与中断处理
-
1.拆开bootpack.c文件。根据设计模式将对应的功能封装成独立的文件。2.初始化pic:pic(可编程中断控制器)：在设计上，cpu单独只能处理一个中断。而pic是将8个中断信号集合成一个中断...
- AI写代码越帮越忙?2025年研究揭露惊人真相
-
近年来，AI工具如雨后春笋般涌现，许多人开始幻想程序员的未来就是“对着AI说几句话”，就能轻松写出完美的代码。然而，2025年的一项最新研究却颠覆了这一期待，揭示了一个令人意外的结果。研究邀请了16位...
- 一键理解开源项目:两个自动生成GitHub代码架构图与说明书工具
-
一、GitDiagram可以一键生成github代码仓库的架构图如果想要可视化github开源项目：https://github.com/luler/reflex_ai_fast，也可以直接把域名替换...
- 5分钟掌握 c# 网络通讯架构及代码示例
-
以下是C#网络通讯架构的核心要点及代码示例，按协议类型分类整理：一、TCP协议（可靠连接）1.同步通信//服务器端usingSystem.Net.Sockets;usingTcpListene...
- 从复杂到优雅:用建造者和责任链重塑代码架构
-
引用设计模式是软件开发中的重要工具，它为解决常见问题提供了标准化的解决方案，提高了代码的可维护性和可扩展性，提升了开发效率，促进了团队协作，提高了软件质量，并帮助开发者更好地适应需求变化。通过学习和应...
- 低代码开发当道，我还需要学习LangChain这些框架吗?| IT杂谈
-
专注LLM深度应用，关注我不迷路前两天有位兄弟问了个问题：当然我很能理解这位朋友的担忧：期望效率最大化，时间用在刀刃上，“不要重新发明轮子”嘛。铺天盖地的AI信息轰炸与概念炒作，很容易让人浮躁与迷茫。...
- 框架设计并不是简单粗暴地写代码，而是要先弄清逻辑
-
3.框架设计3.框架设计本节我们要开发一个UI框架，底层以白鹭引擎为例。框架设计的第一步并不是直接撸代码，而是先想清楚设计思想，抽象。一个一个的UI窗口是独立的吗？不是的，...
- 大佬用 Avalonia 框架开发的 C# 代码 IDE
-
AvalonStudioAvalonStudio是一个开源的跨平台的开发编辑器（IDE），AvalonStudio的目标是成为一个功能齐全，并且可以让开发者快速使用的IDE，提高开发的生产力。A...
- 轻量级框架Lagent 仅需20行代码即可构建自己的智能代理
-
站长之家（ChinaZ.com）8月30日消息:Lagent是一个专注于基于LLM模型的代理开发的轻量级框架。它的设计旨在简化和提高这种模型下代理的开发效率。LLM模型是一种强大的工具，可以...
欢迎 你 发表评论:
- 一周热门
- 最近发表
- 标签列表
-
- 框架图 (58)
- flask框架 (53)
- quartz框架 (51)
- abp框架 (47)
- springmvc框架 (49)
- 分布式事务框架 (65)
- scrapy框架 (56)
- shiro框架 (61)
- 定时任务框架 (56)
- java日志框架 (61)
- mfc框架 (52)
- abb框架断路器 (48)
- beego框架 (52)
- java框架spring (58)
- grpc框架 (65)
- tornado框架 (48)
- 前端框架bootstrap (54)
- orm框架有哪些 (51)
- 知识框架图 (52)
- ppt框架 (55)
- 框架图模板 (59)
- 内联框架 (52)
- cad怎么画框架 (58)
- ssm框架实现登录注册 (49)
- oracle字符串长度 (48)