TimesTen 应用层数据库缓存学习:11. AWT性能监控

2024-02-04 13:48

本文主要是介绍TimesTen 应用层数据库缓存学习:11. AWT性能监控,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

演示环境准备

为了运行以下的例子,我们建立了一个AWT缓存组
Oracle Schema用户:

$ sqlplus tthr/oracle@ttorcl
create table orders(ord_num int primary key, ship_time timestamp not null);
grant select, insert, update, delete on orders to cacheadm;

TimesTen Cache管理用户:

cacheadm>
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP "AWT" FROM"TTHR"."ORDERS" ("ORD_NUM"   NUMBER(38)   NOT NULL,"SHIP_TIME" TIMESTAMP(6) NOT NULL,PRIMARY KEY("ORD_NUM"))
cacheadm> call ttrepstart;
cacheadm> cachegroups;Cache Group CACHEADM.AWT:Cache Group Type: Asynchronous WritethroughAutorefresh: NoAging: No aging definedRoot Table: TTHR.ORDERSTable Type: Propagate1 cache group found.cacheadm>repschemes;Replication Scheme TTREP._AWTREPSCHEME:Element: _1798096                       Type: Table TTHR.ORDERSMaster Store: CACHEDB1_1122 on TIMESTEN-HOL Transmit DurableSubscriber Store: _ORACLE from TIMESTEN-HOL Store: CACHEDB1_1122 on TIMESTEN-HOLPort: (auto)Log Fail Threshold: (none)Retry Timeout: 120 secondsCompress Traffic: DisabledStore: _ORACLE from TIMESTEN-HOLPort: (auto)Log Fail Threshold: (none)Retry Timeout: 120 secondsCompress Traffic: Disabled1 replication scheme found.

OS用户,下面的输出类似于repschems

$ ttrepadmin -showconfig cachedb1_1122Self host "TIMESTEN-HOL", port auto, name "CACHEDB1_1122", LSN 19/2685192, timeout 120, threshold 0
List of subscribers
-------------------Peer name         Host name                 Port    State  Proto Track
----------------  ------------------------ ------  ------- ----- -----
_ORACLE           TIMESTEN-HOL              Auto   Start      38     0Last Msg Sent Last Msg Recv Latency TPS     RecordsPS     
------------- ------------- ------- ------- ---------     
00:00:05      -               -1.00      -1        -1 List of objects and subscriptions
---------------------------------Table details
-------------
Table : TTHR.ORDERS   Timestamp updates : -  Master Name               Subscriber name         
-----------               ---------------         
CACHEDB1_1122             _ORACLE                 

TimesTen Schema用户:

tthr>
insert into orders values(1, sysdate);
ALTER SESSION SET PLSQL_TIMEOUT = 0;
declare ord_num number;      
begin
for i in 1..1000 loop
select max(ord_num) into ord_num from orders;
insert into orders values(ord_num+1, sysdate);
commit;
dbms_lock.sleep( 1 );
end loop;
end;
/

打开 AWT 性能监控

使用ttCacheAWTMonitorConfig打开监控,然后可以用ttRepAdmin查看监控信息。
其中On表示打开,数字16表示16次采样一次,是推荐值,但在我们的例子中,我们采用1,即每次都采样

cacheadm>CALL ttCacheAWTMonitorConfig;
< OFF, 0 >
1 row found.
cacheadm>CALL ttCacheAWTMonitorConfig('off');
< OFF, 0 >
1 row found.
cacheadm>CALL ttCacheAWTMonitorConfig('on');
< ON, 16 >
1 row found.
cacheadm>CALL ttCacheAWTMonitorConfig('on', 1);
< ON, 1 >
1 row found.
cacheadm>CALL ttCacheAWTMonitorConfig;
< ON, 1 >
1 row found.

Display AWT performance results with the ttRepAdmin utility

使用ttRepAdmin的-awtmoninfo 和 -showstatus 选项,例如

$ ttRepAdmin -showstatus -awtmoninfo cachedb1_1122Replication Agent Status as of: 2016-04-21 18:04:39DSN                         : cachedb1_1122
Process ID                  : 8089 (Started)
Replication Agent Policy    : manual
Host                        : TIMESTEN-HOL
RepListener Port            : 42901 (AUTO)
Last write LSN              : 18.65272072
Last LSN forced to disk     : 18.65271808
Replication hold LSN        : 18.65206536Replication Peers:Name                     : _ORACLEHost                     : TIMESTEN-HOLPort                     : 42901 (AUTO) (Connected)Replication State        : STARTEDCommunication Protocol   : 38Name                     : CACHEDB1_1122Host                     : TIMESTEN-HOLPort                     : 0 (AUTO)Replication State        : STARTEDCommunication Protocol   : 38TRANSMITTER thread(s):For                     : _ORACLE (track 0)Start/Restart count   : 1Send LSN              : 18.65245448Transactions sent     : 467Total packets sent    : 856Tick packets sent     : 384MIN sent packet size  : 64MAX sent packet size  : 893AVG sent packet size  : 291Last packet sent at   : 18:04:39Total Packets received: 854MIN rcvd packet size  : 64MAX rcvd packet size  : 120AVG rcvd packet size  : 119Last packet rcvd'd at : 18:04:39TXNs Allocated        : 11TXNs In Use           : 5ACTs Allocated        : 11ACTs In Use           : 5ACTs Data Allocated   : 880Timeout               : 120Adapted Timeout Max   : 120Adapted Timeout Time  : 1461285423current txn           : 0.0Longest batch runtime : 0Longest batch 1st txn : 0.0Longest batch lst txn : 0.0Largest txn (ops)     : 1461231493.12371Largest txn (#ops)    : 1Longest txn (time)    : 0.0Longest txn (secs)    : 0Most recent errors (max 5):TT16025 in repagent.c (line 1227) at 17:34:49 on 04-21-2016TT16285 in transmitter.c (line 1109) at 17:34:49 on 04-21-2016TT16999 in transmitter.c (line 1447) at 17:34:49 on 04-21-2016RECEIVER thread(s):For                     : CACHEDB1_1122 (track 0)Start/Restart count   : 1Transactions received : 467Total packets sent    : 855Tick packets sent     : 0MIN sent packet size  : 64MAX sent packet size  : 120AVG sent packet size  : 119Last packet sent at   : 18:04:39Total Packets received: 2259MIN rcvd packet size  : 64MAX rcvd packet size  : 298AVG rcvd packet size  : 110Last packet rcvd'd at : 18:04:39rxWaitCTN             : 0.0prevCTN               : 0.0current txn           : 0.0serial CTN            : 0.0STA Blk Data Allocated: 32STA Data Allocated    : 4096Longest batch runtime : 0Longest batch 1st txn : 0.0Longest batch lst txn : 0.0Largest txn (ops)     : 1461231493.12371Largest txn (#ops)    : 5Longest txn (time)    : 0.0Longest txn (secs)    : 0AWT Monitoring statistics-------------------------TimesTen processing time : 138.387000 millisecs (100 %)Oracle execute  (SQL execution) time : 0.000000 millisecs (0 %)Oracle execute (PL/SQL execution) time : 0.000000 millisecs (0 %)Time since monitoring was started: 375830.816000 millisecsCacheAwtMethod mode : 1Cache-connect Operational Stats :SQL Operations sent to Oracle : 0Number of update operations : 0Number of update batches    : 0Number of insert operations : 0Number of insert batches    : 0Number of delete operations : 0Number of delete batches    : 0Total number of batches sent: 0Number of bytes sent : 0PL/SQL Operations sent to Oracle : 0Number of update operations : 0Number of insert operations : 0Number of delete operations : 0Number of batches sent : 0Number of bytes sent : 0Number of TimesTen Transactions sent to Oracle (includes retries) : 376Number of retries on TimesTen due to errors on Oracle : 0Number of round trips to Oracle (includes executes, commits and rollbacks) : 0Number of commits on Oracle : 0Number of rollbacks on Oracle : 0Number of rxbatches: 376Number of rxskips: 0Most recent errors (max 5):TT16025 in repagent.c (line 1227) at 17:34:49 on 04-21-2016

注意AWT Monitoring statistics部分。

Using system tables to monitor AWT operations

查询SYS.MONITOR的LAST_LOG_FILE, REPHOLD_LOG_FILE 和 REPHOLD_LOG_OFF列。
它们的含义为:
- LAST_LOG_FILE: Most recent log file present
- REPHOLD_LOG_FILE: Number of last log file held by replication
- REPHOLD_LOG_OFF: Offset in last log file held by replication

SYS.MONITOR只有一行记录, 输出中的18表示log文件是cachedb1_1122.log18

cacheadm>select LAST_LOG_FILE, REPHOLD_LOG_FILE, REPHOLD_LOG_OFF from SYS.MONITOR;
< 18, 18, 63803656 >
1 row found.
cacheadm>select LAST_LOG_FILE, REPHOLD_LOG_FILE, REPHOLD_LOG_OFF from SYS.MONITOR;
< 18, 18, 63854856 >
1 row found.
cacheadm>select LAST_LOG_FILE, REPHOLD_LOG_FILE, REPHOLD_LOG_OFF from SYS.MONITOR;
< 18, 18, 63854856 >
1 row found.

依据下面的原则来判断是非有问题,即如果复制hold的日志文件和产生的最新日志文件差距不断拉大,则表示复制数据的速度赶不上产生数据的速度

If the difference between the value in the LAST_LOG_FILE column and the value in the REPHOLD_LOG_FILE column is increasing over time, and the value in the REPHOLD_LOG_OFF column is increasing slowly or not changing, then the tables are being updated at a faster rate than the updates are being replicated.

如果有问题,可以结合以下的命令再判断

$ ttRepAdmin -receiver -list cachedb1_1122
Peer name         Host name                 Port    State  Proto Track
----------------  ------------------------ ------  ------- ----- -----
_ORACLE           TIMESTEN-HOL              Auto   Start      38     0Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
00:00:04      -               -1.00      -1        -1    1

这篇关于TimesTen 应用层数据库缓存学习:11. AWT性能监控的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/677715

相关文章

Oracle数据库定时备份脚本方式(Linux)

《Oracle数据库定时备份脚本方式(Linux)》文章介绍Oracle数据库自动备份方案,包含主机备份传输与备机解压导入流程,强调需提前全量删除原库数据避免报错,并需配置无密传输、定时任务及验证脚本... 目录说明主机脚本备机上自动导库脚本整个自动备份oracle数据库的过程(建议全程用root用户)总结

SpringBoot监控API请求耗时的6中解决解决方案

《SpringBoot监控API请求耗时的6中解决解决方案》本文介绍SpringBoot中记录API请求耗时的6种方案,包括手动埋点、AOP切面、拦截器、Filter、事件监听、Micrometer+... 目录1. 简介2.实战案例2.1 手动记录2.2 自定义AOP记录2.3 拦截器技术2.4 使用Fi

Spring Boot Actuator应用监控与管理的详细步骤

《SpringBootActuator应用监控与管理的详细步骤》SpringBootActuator是SpringBoot的监控工具,提供健康检查、性能指标、日志管理等核心功能,支持自定义和扩展端... 目录一、 Spring Boot Actuator 概述二、 集成 Spring Boot Actuat

java如何实现高并发场景下三级缓存的数据一致性

《java如何实现高并发场景下三级缓存的数据一致性》这篇文章主要为大家详细介绍了java如何实现高并发场景下三级缓存的数据一致性,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 下面代码是一个使用Java和Redisson实现的三级缓存服务,主要功能包括:1.缓存结构:本地缓存:使

Apache Ignite缓存基本操作实例详解

《ApacheIgnite缓存基本操作实例详解》文章介绍了ApacheIgnite中IgniteCache的基本操作,涵盖缓存获取、动态创建、销毁、原子及条件更新、异步执行,强调线程池注意事项,避免... 目录一、获取缓存实例(Getting an Instance of a Cache)示例代码:二、动态

一文解密Python进行监控进程的黑科技

《一文解密Python进行监控进程的黑科技》在计算机系统管理和应用性能优化中,监控进程的CPU、内存和IO使用率是非常重要的任务,下面我们就来讲讲如何Python写一个简单使用的监控进程的工具吧... 目录准备工作监控CPU使用率监控内存使用率监控IO使用率小工具代码整合在计算机系统管理和应用性能优化中,监

虚拟机Centos7安装MySQL数据库实践

《虚拟机Centos7安装MySQL数据库实践》用户分享在虚拟机安装MySQL的全过程及常见问题解决方案,包括处理GPG密钥、修改密码策略、配置远程访问权限及防火墙设置,最终通过关闭防火墙和停止Net... 目录安装mysql数据库下载wget命令下载MySQL安装包安装MySQL安装MySQL服务安装完成

MySQL进行数据库审计的详细步骤和示例代码

《MySQL进行数据库审计的详细步骤和示例代码》数据库审计通过触发器、内置功能及第三方工具记录和监控数据库活动,确保安全、完整与合规,Java代码实现自动化日志记录,整合分析系统提升监控效率,本文给大... 目录一、数据库审计的基本概念二、使用触发器进行数据库审计1. 创建审计表2. 创建触发器三、Java

Zabbix在MySQL性能监控方面的运用及最佳实践记录

《Zabbix在MySQL性能监控方面的运用及最佳实践记录》Zabbix通过自定义脚本和内置模板监控MySQL核心指标(连接、查询、资源、复制),支持自动发现多实例及告警通知,结合可视化仪表盘,可有效... 目录一、核心监控指标及配置1. 关键监控指标示例2. 配置方法二、自动发现与多实例管理1. 实践步骤

MySQL深分页进行性能优化的常见方法

《MySQL深分页进行性能优化的常见方法》在Web应用中,分页查询是数据库操作中的常见需求,然而,在面对大型数据集时,深分页(deeppagination)却成为了性能优化的一个挑战,在本文中,我们将... 目录引言:深分页,真的只是“翻页慢”那么简单吗?一、背景介绍二、深分页的性能问题三、业务场景分析四、