如何在LoadRunner中监控oracle数据库

使用LR自带的监控引擎：

在安阳等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供做网站、网站设计 网站设计制作按需规划网站,公司网站建设,企业网站建设,品牌网站建设,营销型网站,成都外贸网站制作,安阳网站建设费用合理。

1，在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击Add如下所示：

在这里可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。

2，在Resource Measurements on:IP区域点击添加，弹出对话框如下：

3，输入信息如图。点击OK，如下：

如何监控oracle自动增长表空间

1.跟踪数据库空间增长

SELECT SUM(MB_ALLOC)/1024 GB_DB_SIZE FROM

(SELECT SUM(ROUND(bytes_used/(1024*1024),2) + ROUND(bytes_free/(1024*1024),2)) MB_ALLOC

FROM V$temp_space_header, dba_temp_files

WHERE V$temp_space_header.file_id (+) = dba_temp_files.file_id

UNION

SELECT SUM(BYTES)/(1024*1024) MB_ALLOC FROM dba_data_files);

2.下面例子除了undo和temp表空间外，将其他表空间的的使用情况记录每周插入db_spaec_hist表，以便查询：

Create the table for database size history create table db_space_hist (

timestamp date,

total_space number(8),

used_space number(8),

free_space number(8),

pct_inuse number(5,2),

num_db_files number(5)

);

Create the procedure db_space_history CREATE OR REPLACE PROCEDURE db_space_history AS

BEGIN

INSERT INTO db_space_hist

SELECT SYSDATE, total_space,

total_space-NVL(free_space,0) used_space,

NVL(free_space,0) free_space,

((total_space - NVL(free_space,0)) / total_space)*100 pct_inuse,

num_db_files

FROM ( SELECT SUM(bytes)/1024/1024 free_space

FROM sys.DBA_FREE_SPACE WHERE tablespace_name NOT LIKE '%UNDO%') FREE,

( SELECT SUM(bytes)/1024/1024 total_space,

COUNT(*) num_db_files

FROM sys.DBA_DATA_FILES WHERE tablespace_name NOT LIKE '%UNDO%') FULL;

COMMIT;

END;

/

Create the job that runs once in a week DECLARE

X NUMBER;

BEGIN

SYS.DBMS_JOB.SUBMIT

(

job = X

,what = 'SYS.DB_SPACE_HISTORY;'

,next_date = TO_DATE('22/02/2008 19:40:28','dd/mm/yyyy hh24:mi:ss')

,INTERVAL = 'TRUNC(SYSDATE+7)'

,no_parse = FALSE

);

END;

3.做周期性监控

select * from db_space_hist order by timestamp desc;

4.查询结果（每月数据库的增长情况），统计的出发条件为createion_time.

SELECT TO_CHAR(creation_time, 'RRRR Month') "Month", round(SUM(bytes)/1024/1024/1024) "Growth in GBytes"

FROM sys.v_$datafile

WHERE creation_time SYSDATE-365

GROUP BY TO_CHAR(creation_time, 'RRRR Month');

Month Growth in GBytes

-------------- ----------------

2008 December 1331

2008 November 779

2008 October 447

2009 April 797

2009 August 344

2009 February 505

2009 January 443

2009 July 358

2009 June 650

2009 March 452

2009 May 1787

2009 October 255

2009 September 158

如何监控oracle数据库性能

oracle的性能判断需要综合数据库的多个运行指标来判断：

1、进程数量和占用cpu：这个主要看有没有长时间占用cpu的进行。通常会判断大出sql，需要优化；这个可以用执行计划或者awr报告查看；

2、内存占用：主要用系统命令查看ora_占用和系统总内存的比例，swap的使用率；通常swap使用率低就没事；这个主要使用系统命令；

3、磁盘占用率：防止磁盘空间不足，需要的主要在系统和用户表空间、RMAN等操作上；这个主要使用系统命令；RMAN命令查看

如何监控Oracle数据库中长时间运行的进程

监控Oracle 数据库中长时间运行进程的两种方式,通过这些方 法,我们可以监控单条语句的 长时间操作,监控存储过程的运行进度,甚至自己'生成'进度信息. 关键词:监控进度V$SESSION_LONGOPS 当Oracle 存储过程运行时间较长时,我们希望客 户端能了解到它在后台执行的状况或者进度信息(类 似WINDOWS 安装软件时的进度条信息),这样可以知 道运行在后台的应用进程是否终止或者休眠,更近一 步要求,最好能知道进行到哪一步骤,还有多少时间才 能完成. 简单到一条SQL 语句的情况,如果执行时间较长, 我们如何得到它的运行状况?是否后台还在运行?虽 然可以查看SQL 的执行计划了解它的执行步骤,但如 何知道它运行到哪一个步骤了呢?如何才能估计出它 的合理的较为精确的执行时间呢? Oracle 数据库前端发出执行命令后,进程在后台 执行,普通开发人员一般无法了解到后台在做什么,一 般采用的方法是用DBMSOUTPUT.PUT_LINE 来打印出 来,但DBMS—OUTPUT.PUT—LINE 打印的信息受缓冲区 大小限制,如果信息较多就容易溢出,而且如果存储过 程执行时间较长,只有在其执行完后,这些信息才会打 印出来,这就增加了调试周期,影响了调试效果.有的 开发人员在存储过程中通过写日志表的形式来记录进 度,但需要COMMIT 后其他进程才能看到这些日志信 息,而在某些控制结构中(如游标CURSOR 循环)COM— MIT,则很容易引起ORA 一01555 错误,造成程序出错. 下面介绍两种监控方法. 如何监控单条长语句从ORACLE8 开始,出现一个新的动态视图:V $SESSION_LONGOPS,从这个视图可以获知一些操作 (如全表扫描,并行查询,RMAN,排序等)的执行进度, 我们先来了解一下V$SESSION—LONGOPS 视图的一些 重要字段: 列说明 sID 会话标识 5ERIAL#会话序列号 OPfE 操作的简短描述 TARG 盯操作的对象,如xx TAR~_DESC目标描述 SOFAR 目前已执行单位数目 ToTAIWORK 总单位数目 UNlTS 单位 START_TIME 开始执行时间 LAST_ UPDATE_TIME 统计数据最后更新时间 TIME_ REMAINING 估计剩余时间c ELAPSED_SECONDS 已执行时间(秒) MEsSAGE 统计数据汇总信息 USERA^^E 用户名 ~L_ADDRES5 语句的地址,,用于和V$sql_text 等关联 语句的hash 地址,用于和V$sql_texlSQLHASH VALUE等关联 这个动态视图显示各个运行时间超过6 程.这些进程包含许多备份和恢复功能,统计数据收集,查询等. 执行以下语句就可以得到数据库中各个长时间操 作的进程信息: select'Icfromv$sesslon_ longopswheretime_ re- malnlng0 我们也可以用图形化工具查看,如TOAD,OEM中 均可查看长操作进程进度信息. Oracle 自带的管理工具OracleEnterpriseManager (OEM)提供了图形化查看长操作的功能,如: 计算机系统应用2007 Quest公司的数据库管理工具TOAD 也可以看到 长操作信息,如: 表的统计信息. 长时问运行的SQL 语句可以用V$SESSION—LON? 为了能监控到查询进程执行的进度,必需使用 CBO 优化器并且: 设置TlMED—STATISTICS或者SQL—TRACE 用ANALYZE语句或者DBMS—STAT 包收集相关 108 实践经验P 帕cficalExpen GOPS来监控.实际上,长时间运行的存储过程也可以 监控.那是否任何操作都可以通过这个视图来监控进 度呢?很遗憾,V$SESSION—LONGOPS 只会报告它认为 耗时长的操作.对于NEsTEDLOOP/UNIQUEINDEX READS/INDEXRANGEScANS 等执行速度很快的操作, 2007 期计算机系统应用由于它们执行一般不超过6 秒,因此将不会出现在V $SESSION—LONGOPS 如何监控自定义存储过程单条长语句可以用上面的方法监控,Oracle 动生成V$SE.SSION— LONGOPS 记录.那么存储过程中 有许多小操作,如何监控进度呢?其实,我们也可以手 工生成V$SESSION—LONGOPS 记录,方法是调用DBMS APPLICATION—INFO 包来生成自定义进度信息. 从Oracle7.2 开始,提供了DBMS—APPLICATION— INFo 包,通过调用这个包,应用可以将自己的名字和 动作填写到V$SESSION 和V$SQLAREA 的MODULE ACTION列中.V$SESSION 列出每个会话的用户名,操 作系统机器名,终端名,程序名等. 应用可以在执行模块时设置模块名和动作名,模 块名一般是甩户自定义的.而动作名一般描述模块中 的当前执行的事务的名字. DBMSAPPLICATION_INFO 包包含以下过程 SET_ MODULE 设置当前运行程序的模块名 SET__AEl'ION 设置当前模块的当前动作名 SESSION—LON-在V$SESSIONLONGOPS视图中 GoPS 插入一行进度信息 SETMODULE过程设置模块名和动作名: createorreplaceproceduredel—cust(v_cust—Id varchar2) begindbms—— application—— info.set— module(module—— name="delcust". actlon_name="deletetablecust)i deletefromcustwherecustld=v_ cusLId; dbms_appllcatlon— Info.seLmodule(,); end;以上设置的模块名和动作名可以通过查询V $sqlarea 获取. 如:selectsql—text,module,actionfromv $sqlareawheremodule="del_cust: sql_textmoduleadion Deletefr0mcustdel_ custdeletetableoust 1rowselected. SET_SESSION—LONGOPS 过程用于在V$session— longops 中插入一行,开发人员可以调用此过程设置长 时间操作的状态信息,这样,任何其他其他会话都可以 看到这个进度信息.如下例所示: declare nohlntnumberdefaultdbmsapplicatlon_info.set_ session— Iongops_ nohint; IdndexnumberdefaultInohlnt: slnonumber;begin forlIn1..8888888888 loop update....; dbms_ appllcaflon— Info.setsesslon_ longops (rlndex=l_rlndex, slno=I_slno. op_name="updateahugetable. target=126, target_desc='.msgdescription context=0.sOfar=j. totalwork=8888888888. units=loops endloop;end; 然后,从另一个会话来执行以下语句selectfromv$sesslon_ longopswheretlmere? malnlng0; 也可以用图形化工具TOAD 或OEM来查看. 因此,采用本文说明的方法,Oracle 开发人员可以 比较方便的监控长操作进程的进度信息,也可以自己 设置监控信息,来了解后台存储过程的运行效率.甚 至,可以在存储过程或SQL 语句提交执行后马上观察 其执行进度,如果比较缓慢,则可以中断其执行,进行 调优,从而缩短调试周期,提高开发效率.

文章标题：监控oracle怎么做 oracle 数据库监控
文章起源：http://pwwzsj.com/article/hjpiid.html