Procwatcher: Script to Monitor and Examine Oracle DB and Clusterware Processes

Procwatcher是一款用于监控Oracle数据库及集群进程的工具,能够收集进程堆栈跟踪和SQL数据,适用于解决会话级挂起、性能问题及内存管理等场景。本文档详细介绍了其安装要求、适用场景及命令操作。

 

 

Purpose

Procwatcher is a tool to examine and monitor Oracle database and/or clusterware processes at an interval.   The tool will collect stack traces of these processes using Oracle tools like oradebug short_stack and/or OS debuggers like pstack, gdb, dbx, or ladebug and collect SQL data if specified.

 

Requirements

  • Must have /bin and /usr/bin in your $PATH
  • Have your instance_name or db_name set in the oratab and/or set the $ORACLE_HOME env variable.(PRW searches the oratab for the SID it finds and if it can't find the SID in the oratab it will default to $ORACLE_HOME). Procwatcher cannot function properly if it cannot find an $ORACLE_HOME to use.
  • Run Procwatcher as the oracle software owner if you are only troubleshooting homes/instances for that user. If you are troubleshooting clusterware processes (EXAMINE_CLUSTER=true or are troubleshooting for multiple oracle users) run as root.
  • If you are monitoring the clusterware you must have the relevant OS debugger installed on your platform; PRW looks for:

Linux - /usr/bin/gdb
HP-UX and HP Itanium - /opt/langtools/bin/gdb64 or /usr/ccs/bin/gdb64
Sun - /usr/bin/pstack
IBM AIX - /bin/procstack or /bin/dbx
HP Tru64 - /bin/ladebug

 

 

Procwatcher is Ideal for:

  • Session level hangs or severe contention in the database/instance. See Note: 1352623.1
  • Severe performance issues. See Note: 1352623.1
  • Instance evictions and/or DRM timeouts.
  • Clusterware or DB processes stuck or consuming high CPU (must set EXAMINE_CLUSTER=true and run as root for clusterware processes)
  • ORA-4031 and SGA memory management issues. (Set sgamemwatch=diag or sgamemwatch=avoid4031 (not the default). See Note: 1355030.1
  • ORA-4030 and DB process memory issues. (Set USE_SQL=true and process_memory=y).
  • RMAN slowness/contention during a backup. (Set USE_SQL=true and rmanclient=y).

Procwatcher is Not Ideal for...

  • Node evictions/reboots. In order to troubleshoot these you would have to enable Procwatcher for a process(es) that are capable of rebooting the machine. If the OS debugger suspends the processs for too long *that* could cause a reboot of the machine. I would only use Procwatcher for a node eviction/reboot if the problem was reproducing on a test system and I didn't care of the node got rebooted. Even in that case the INTERVAL would need to be set low (30) and many options would have to be turned off to get the cycle time low enough (EXAMINE_BG=false, USE_SQL=false, probably removing additional processes from the CLUSTERPROCS list).
  • Non-severe database performance issues. AWR/ADDM/statspack are better options for this...
  • Most installation or upgrade issues. We aren't getting data for this unless we are at a stage of the installation/upgrade where key processes are already started.

 

Procwatcher User Commands

To start Procwatcher:

./prw.sh start



Or if you want to start on all nodes in a clustered environment:

./prw.sh start all




To stop Procwatcher: :

./prw.sh stop



Or if you want to stop on all nodes in a clustered environment:

./prw.sh stop all



To check the status of Procwatcher:

./prw.sh stat

 

To package up Procwatcher files to upload to support:

./prw.sh pack



All user syntax available:

./prw.sh help

 

代码转载自:https://pan.quark.cn/s/7f503284aed9 Hibernate的核心组件总数达到五个,具体包括:Session、SessionFactory、Transaction、Query以及Configuration。 这五个核心组件在各类开发项目中都具有普遍的应用性。 借助这些组件,不仅可以高效地进行持久化对象的读取与存储,还能够实现事务管理功能。 接下来将通过图形化的方式,逐一阐述这五个核心组件的具体细节。 依据所提供的文件内容,可以总结出以下几个关键知识点:### 1. SSH框架详细架构图尽管标题提及“SSH框架详细架构图”,但在描述部分并未直接呈现关于SSH的详细内容,而是转向介绍了Hibernate的核心接口。 然而,在此我们可以简要概述SSH框架(涵盖Spring、Struts、Hibernate)的核心理念及其在Java开发中的具体作用。 #### Spring框架- **定义**:Spring框架是一个开源架构,其设计目标在于简化企业级应用的开发流程。 - **特点**: - **分层结构**:该框架允许开发者根据实际需求选择性地采纳部分组件,而非强制使用全部功能。 - **可复用性**:Spring框架支持创建可在不同开发环境中重复利用的业务逻辑和数据访问组件。 - **核心构成**: - **核心容器**:该部分包含了Spring框架的基础功能,其核心在于`BeanFactory`,该组件通过工厂模式运作,并借助控制反转(IoC)理念,将配置和依赖管理与具体的应用代码进行有效分离。 - **Spring上下文**:提供一个配置文件,其中整合了诸如JNDI、EJB、邮件服务、国际化支持等企业级服务。 - **Spring AO...
In SystemVerilog, there are several types of coverage used to assess the thoroughness of testing. ### Code Coverage - **Line Coverage**: It ensures that each line of code in the design is executed at least once. For example: ```systemverilog module code_coverage_example; reg a, b, c; always @(*) begin c = a & b; // This line's execution is tracked by line coverage end endmodule ``` - **Branch Coverage**: Guarantees that all possible branches of conditional statements (such as if - else, case statements) are executed. ```systemverilog module branch_coverage; reg [1:0] sel; reg out; always @(*) begin if (sel == 2'b00) begin out = 1'b0; end else if (sel == 2'b01) begin out = 1'b1; end else begin out = 1'bx; end end endmodule ``` - **Condition Coverage**: Verifies all possible outcomes of conditional expressions in the design, ensuring that all possible value combinations of conditions are tested. ```systemverilog covergroup condition_cg @(posedge clk); cond_cover: coverpoint (condition1 && condition2); endgroup ``` ### Functional Coverage Functional coverage focuses on whether the functional features of the design are fully tested. It is defined based on the design's functional specifications. For example, for a processor, functional coverage may include the execution of the instruction set and testing of different operation modes. ```systemverilog covergroup functional_cg; opcode_cover: coverpoint cpu.opcode; mode_cover: coverpoint cpu.mode; endgroup ``` ### Assertion Coverage Assertion coverage is used to verify whether the assertions in the design are triggered. Assertions are statements used to check if the design behavior meets expectations. By assertion coverage, it can be ensured that assertions are correctly executed during testing. ```systemverilog module assertion_coverage; reg clk, rst; reg [7:0] data; always @(posedge clk) begin assert (data < 8'hFF) else $error("Data out of range"); end endmodule ``` ### Toggle Coverage Toggle coverage measures the state changes of signals during testing, ensuring that all possible signal transitions (from 0 to 1, from 1 to 0) are tested. ```systemverilog covergroup toggle_cg @(posedge clk); toggle_cover: coverpoint signal iff (enable) { bins rise = (0 => 1); bins fall = (1 => 0); } endgroup ``` ### Path Coverage Path coverage is used to verify the behavior of different signal paths in the design, ensuring that all possible signal propagation paths are tested. ```systemverilog module path_coverage; reg a, b, c, d; wire e, f; assign e = a & b; assign f = c | d; wire out = e ^ f; endmodule ``` ### Interface Coverage Interface coverage focuses on the usage of interfaces in the design, ensuring that all functions and protocols of the interface are fully tested. For example, for a bus interface, interface coverage may include different bus transaction types and address ranges. ```systemverilog covergroup interface_cg; transaction_type_cover: coverpoint bus_if.transaction_type; address_range_cover: coverpoint bus_if.address; endgroup ``` ### Transaction Coverage Transaction coverage is based on transactions in the design. It ensures that all possible transaction types and sequences are tested. For example, for a communication system, transaction coverage may include different message types and message lengths. ```systemverilog covergroup transaction_cg; message_type_cover: coverpoint comm_system.message_type; message_length_cover: coverpoint comm_system.message_length; endgroup ``` ### State Machine Coverage State machine coverage verifies the behavior of state machines, ensuring that all states and state transitions of the state machine are fully tested, which helps to check if the state machine performs state transitions correctly according to the design specifications and avoid issues such as state loss or illegal state transitions [^1]. ```systemverilog covergroup state_machine_cg @(posedge clk); state_transition: coverpoint state_machine.current_state -> state_machine.next_state; endgroup ``` ### Block Coverage Block coverage focuses on the execution of code blocks, ensuring that each code block (such as always blocks, tasks, functions) in the design is executed at least once. ```systemverilog covergroup block_cg; always_block_cover: coverpoint always_block_executed; task_cover: coverpoint task_executed; endgroup ``` ### Weighted Coverage Weighted coverage can be used to specify the proportion of a certain coverage point in the overall. For example, when covering a counter, the goal is to observe a range rather than collect all cases. In this case, option.weight = 0 can be set, which means that the coverage rate of this group or point is not calculated in the overall coverage statistics [^2]. ```systemverilog covergroup weighted_cg; coverpoint counter { option.weight = 5; bins small = {[0:10]}; bins medium = {[11:50]}; bins large = {[51:$]}; } endgroup ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值