Oracle可视化性能图表之 “CPU 内存网络等数据性能分析”

来源：这里教程网时间：2026-03-03 19:58:21 作者：

Oracle 性能视图查看系统CPU 内存磁盘存储等性能指标主要保存在 V$SYSMETRIC_HISTORY及DBA_HIST_SYSMETRIC_HISTORY 相关视图上。此次我们以网络带宽传输速率：例如：目标是在Data Guard环境中尽可能快地传输和应用重做。为了实现这一点，我们必须根据主数据库上的重做生成率计算所需的网络带宽。计算网络带宽的公式(假设TCP/IP网络开销保守为30%)为: Required bandwidth = ((Redo rate in Megabytes per sec. / 0.70) * 8)= bandwidth in Mbps 使用Oracle Statspack实用程序来精确测量重做率。根据业务，我们应该有一个很好的想法，什么是你的正常业务活动的高峰时期。例如，您可能正在运行一个在线商店，从历史上看，每个星期一上午10点到下午2点之间的4小时是活动高峰。或者，你可能正在运行一个商业数据库，它会在每周四凌晨1点到3点之间的两个小时内批量加载一个新目录。请注意，我们所说的“正常”商业活动——这意味着在一年中的某些日子里，你可能会看到比平时更多的业务量，例如，在母亲节或情人节前的2-3天，在线花店的业务。就在那些日子里，您可能会分配比平时更高的带宽，而您可能不会将其视为“正常”的业务活动。但是，如果这种周期性的流量激增是业务操作的一部分，则必须在重做率计算中考虑它们。在业务的高峰期间，定期运行Statspack快照。例如，您可以在高峰时间运行它三次，每次持续五分钟。Statspack快照报告将在报告开头附近的“Load Profile”部分下包含一个“Redo size”行。这一行包括快照间隔期间重做大小的“每秒”和“每个事务”测量值(以字节为单位)。记下“每秒”的值。取这三个快照中“重做大小”“每秒”的最大值，这就是您的峰值重做生成速率。注意，如果主数据库是RAC数据库，则必须在每个RAC实例上运行Statspack快照。然后，对于每个Statspack快照，将每个实例的“Redo Size Per Second”值相加，以获得主数据库的净峰值重做生成率。记住这一点在RAC主数据库中，每个节点生成自己的重做，并独立地将重做发送到备用数据库——因此，我们将每个RAC节点的重做速率求和，以获得数据库的净峰值重做速率。作为一种选择，你也可以从V$SYSMETRIC_HISTORY中获得“每秒重做率字节数”，例如。 SQL> select * from v$sysmetric_history where metric_name = 'Redo Generated Per Sec'; 或在rda中输出: 性能- AWR报告-统计:“重做大小” 例如：Let us assume the redo rate is a 500 KB/sec.

Required bandwidth = ((Redo rate bytes per sec. / 0.70) * 8) / 1,000,000 = bandwidth in Mbps Required bandwidth = ((512000/0.70) * 8) /1,000,000 Required bandwidth = 5.46 Mbps

Also see Data Guard Redo Transport & Network ConfigurationAndMeasuring Network Capacity using oratcptest (Doc ID 2064368.1)for further Hints and Best Practices to setup the Network for Data Guard Log Transport Services 注意一 CDB模式数据库性能数据视图区别：For PDBs, it is expected to see no rows from the sysmetric related views e.g., v$sysmetric, v$sysmetric_history, v$sysmetric_summary etc. PDBs are not intended to see CDB-wide (con_id=0) metric data. Instead they can only see information for their own database with CON_ID=PDB_ID.PDB level system metric related information can be found from the following views: v$con_sysmetric v$con_sysmetric_history v$con_sysmetric_summary 注意二数据库性能视图DBA_HIST_SYSMETRIC_HISTORY并不会抓取所有的metric 指标 This is expected behavior as documented in internal bug discussion.The view DBA_HIST_SYSMETRIC_HISTORY will only display a few default metrics from V$SYSMETRIC_HISTORY. Not all metrics will be displayed in this view.Additional metrics can be populated when user created Threshold-based Server Generated Alerts are generated on the metric.However, even if the thresholds have been defined, DBA_HIST_SYSMETRIC_HISTORY will only be populated if the thresholds are violated and alerts are issued to EM.Metric Thresholds can be set either via Enterprise Manager or via DBMS_SERVER_ALERT.SET_THRESHOLD() API.New Metric Thresholds can be set either via Enterprise Manager or via DBMS_SERVER_ALERT.SET_THRESHOLD() API, but be aware DBA_HIST_SYSMETRIC_HISTORY not populated unless threshold is hit. 相关参考文档：‘https://docs.oracle.com/cd/E11882_01/server.112/e10803/config_dg.htm#CEGHIEIE’ ‘https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/V-SYSMETRIC_HISTORY.html#:~:text=V%24SYSMETRIC_HISTORY%20displays%20all%20system%20metric%20values%20available%20in,one-interval%20only%29%20metrics%20are%20displayed%20by%20this%20view.’ ‘https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/DBA_HIST_SYSMETRIC_HISTORY.html#:~:text=DBA_HIST_SYSMETRIC_HISTORY%20externalizes%20all%20available%20history%20of%20the%20system,entire%20set%20of%20data%20kept%20in%20the%20database.’