Oracle Enterprise Manager 12c 新特性:实时Real-Time Addm

在Oracle Enterprise Manager 12c中引入了Real-Time addm的新特性。 DBA可以直接从EM界面上启动实时ADDM(Automatic Database Diagnostic Monitor )信息收集, 也叫做Emergency ADDM。

 

Emergency ADDM adds performance diagnostics for databases suffering from severe performance problems. Real-time ADDM. You can connect to the database and investigate what is going on when you cannot connect to the database because it is hanging on

 

 

登录EM 12c后Target -> Database -> 选择指定的数据库 -> Performance -> Real-Time Addm:

 

 

进入”Real-Time ADDM”后点选start按钮,第一次使用会出现”Required PL/SQL package not installed. Use the link below to deploy the package. The error message from the server is:Package dbsnmp.prvt_eaddm is not found” 的错误:

 

 

使用Real-Time Addm要求预安装dbsnmp.prvt_eaddm包,点选下方的PL/SQL Package Deployment链接,进入Package Deployment页面,选择合适的身份认证,并install。

 

 

进入Job Run: DATABASE MANAGEMENT PL/SQL DEPLOYMENT JOB页面等待作业完成。

以测试为目的登录数据库并运行以下消耗CPU的SQL语句(不要用在生产库!):

 

 select count(1) from obj$,obj$,obj$;

 

回到”Real-Time ADDM”页面再次点击start , 等待一段时间后会自动stop,如下图:

 

 

Real-Time Addm有所发现,这里的Number of finding =1 ,点击Findings 可以看到Prority、Performance Impact、Finding Details等信息:

 

 

当出现服务进程hang的情况,例如进程因”enq: TM contention”  队列锁而长久等待,则可以从hang data栏获取hang analysis Final Blocker 和 blocking session的信息, 找出阻塞的源头:

 

 

 

 

上图中列出了Blocker chains ,一定程度上可以替代hanganalyze dump。

statistics栏给出了实例的一些属性和近期的系统度量system metrics:

 

 

Real-Time Addm可以帮助我们快速定位性能和挂起hang问题,而且给出初步的分析,这要比我们使用脚本一步步查来的快捷多了。

11g中的db_block_checking参数

初始化参数DB_BLOCK_CHECKING控制Oracle如何全面检查读写的每个数据块的完整性。启用的检查界别是环境中的故障承受级别(通常很低)与连续检查块所需的开销折中的结果。在11g中db_block_checking参数有了更多的选项,以满足不等的块检验粒度:

SQL> alter system set db_block_checking=AA;
alter system set db_block_checking=AA
*
ERROR at line 1:
ORA-00096: invalid value AA for parameter db_block_checking, must be from among FULL, TRUE, MEDIUM, LOW, OFF, FALSE

/* 可选的有 OFF=FALSE,FULL=TRUE以及MEDIUM和LOW */

不同的DB_BLOCK_CHECKING选项对应不同的检查粒度:

  • OFF或FALSE 不执行任何检查块的操作
  • LOW 在内存中更改块或从磁盘中读取块后对块进行基本检查,其中包括RAC环境中在实例间传输块的情形
  • MEDIUM 包括所有LOW检查,另加检查所有非IOT(索引组织表)块
  • FULL或TRUE 包括所有LOW和MEDIUM检查,另加检查索引块

在客户愿意承担性能开销的前提下,Oracle建议使用FULL值。默认值是OFF,但仍始终启用针对SYSTEM表空间的FULL块检查功能(受到隐式参数_db_always_check_system_ts的控制,默认为TRUE)。通常认为块检查开销的范围在1%~10%之间,在OLTP环境中更接近于10%。
[Read more…]

11g新特性SQL执行计划管理(SQL Plan Management) (1)

数据库系统性能受到查询执行的严重影响。然而SQL语句的执行计划可能因统计信息变化,优化参数变化或方案定义变化等原因而意外改变,Oracle Optimizer优化器往往无法在没有人工干预的情况下准确进化执行计划。在无法保证新的执行计划总是趋于变得更好的情况下,用户倾向于通过存储大纲(stored outline)或锁定统计信息来保证执行计划的问题。然而使用这些方式将不可避免地丧失利用到新的优化器特性以改善SQL语句性能的优势。在保证当前可被接受执行计划的前提下,仅允许采用那些更好的,获益更多的执行计划才是终极方案。

Oracle Database 11g是在解决这一SQL执行计划上处于市场领先地位。SQL Plan Management(SPM)提供了一个完全透明且可控的执行计划进化的框架。在SPM的帮助下优化器自动管理执行计划并保证只有已知或已确认的执行计划才被采用。当一个新的计划出现时,Oracle将不会采用它,直到确认其与当前的执行计划有着相当的,或更好的性能。

SQL Plan Management(SPM)保证数据库运行时性能绝不因为执行计划的改变而大幅下降。为了确保这一点,仅仅那些已被接受的(accepted or trusted)的执行计划将被采用;任何计划的进化都将被追踪并仅在其被评价为无损于性能或有益于性能后被采纳。

SPM主要由三个部分组成:

1.执行计划基线捕捉

创建SQL执行计划基线意味着接受(或者说信任)相关SQL语句的执行计划。SQL计划基线存储在历史计划中,历史计划保存在SQL Management BASE(SMB)中,SMB位于SYSAUX表空间上。

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE	11.2.0.2.0	Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

SQL> select occupant_name,space_usage_kbytes  from v$sysaux_occupants where occupant_name like '%SQL%';

OCCUPANT_NAME                                                    SPACE_USAGE_KBYTES
---------------------------------------------------------------- ------------------
SQL_MANAGEMENT_BASE                                                            3776

2.SQL计划基线选择

保证仅采用SQL计划基线中已被信任的执行计划,并追踪计划历史中所有新的执行计划。计划历史中包括了受信任的和不受信任的执行计划。不受信任的执行计划可能是未被检验的(unverified)或被拒绝的(rejected)。
[Read more…]

11g新特性之闪回事务处理取消

在Oracle database10g中,Oracle引入了两个闪回特性,即闪回版本查询和闪回事务处理查询,允许撤销跟随在数据库中逻辑错误后面的数据所发生的错误变化。在一个可以的数据错误之后,首先使用闪回版本查询来确定属于该错误事务处理的表行的版本。在确定出错的事务处理后,使用闪回事务处理查询审计该事务所做的所有变化。使用由闪回事务处理查询的undo_sql列提供的SQL代码,撤销由错误事务处理所做的变化。这样,闪回事务处理提供了强大的撤销数据库中逻辑错误的办法。

在Oracle 11g中,可以使用新的闪回事务处理取消特性完成必须由闪回版本查询和闪回事务处理查询共同完成的任务。通常一个数据错误会引起其他依赖事务处理使用有错的数据执行。闪回事务处理取消时一个新的逻辑恢复特性,它使你返回目标事务处理,并使依赖事务处理回到原来的状态。闪回事务处理取消特性识别并修正内部的事务处理以及以及依赖的事务处理,从而彻底撤销逻辑数据错误的作用。撤销插入时,更新和删除操作的完整集合确保了事务处理的原子性和一致性原理被维护。这样,当数据库联机时,通过执行一个取消命令(单独运行transaction_backout过程),就可以执行数据的逻辑恢复。如果正在使用Database Console,点击一下就可以取消事务。依赖事务处理与目标事务处理可能有以下几种关系:

  • 写后写(write-after-write,WAW)关系,依赖事务处理更改了由目标事务处理更改的相同数据。
  • 主键约束关系,依赖事务处理插入与目标事务处理删除的相同的逐渐。

通过执行补偿事务处理(compensating transactions,它将受不要的事务处理影响的数据恢复到原来状态),数据库撤销事务处理的变化。闪回事务处理依靠撤销数据(以及为撤销块产生的重做)来创建补偿事务处理。因此,要撤销一组不要的事务处理,需要同时撤销数据和归档重做日志。

  1. 闪回事务处理取消的先觉条件 :必须首先开启数据库的补全日志(supplemental logging),然后给要使用闪回事务处理特性的用户授予特定的权限。为了启动数据库补全日志,使用以下命令:alter database add supplemental log data; alter database add supplemental log data (primary key) columns。 除了启动补全日志外,还要给闪回事务处理取消特性的用户授予以下权限: grant execute on dbms_flashback to hr; grant select any transaction to hr; 用户必须有flashback 权限,可以通过授予DBMS_FLASHBACK表的execute权限来授予。另外,用户还需要select any transaction权限。如果用户想要取消属于自己的模式中的事务处理,则无需增加权限。但是,如果某个用户想要取消其他模式的事务处理,还必须授予他对手事务处理取消影响的所有表的DML权限。
  2. 使用transaction_backout过程 补偿事务处理的思想对于事务处理取消特性至关重要。通过使用撤销数据,一个补偿事务处理可以取消一个或多个事务处理。使用DBMS_FLASHBACK包的transaction_backpout过程很容易回退不想要的事务处理。以下是transaction_backout过程的结构:

dbms_flashback.transaction_backout(
numtxns NUMBER,
xids    xid_array,
options BINARY_INTEGER DEFAULT NOCASCADE,
scnhint NUMBER DEFAULT 0);

transaction_backout过程有四个参数,如下:

  • NumTxns:此参数为被取消的事务处理的数量。
  • Names: 此参数为被取消的事物处理的列表(按名字排序)。
  • Timehint: 如果你按名字标识事务处理,则可以提供一个时间提示,如在事务处理开始前的某个时间。
  • Options:该事务指定某个事务处理及其依赖的事务处理被取消的顺序。

transaction_backout过程只分析事务处理之间的依赖性,执行DML操作,并提供一个报告。但是此过程不自动提交这些DML操作。该过程所做的就是通过锁定受影响的表行即表本身,保证其他事务处理的依赖性不受取消操作影响。必须明确执行commit语句,确保永久取消。

数据库将自动为取消操作提供一个事务处理名,但是由你给该操作明确的名字有利于后来的神奇。如果transaction_backout过程的执行成功完成。则表明已经取消了单个事务处理且无任何依赖事务处理。一个取消操作花费时间的多少将依赖于被取消的事务处理产生的重做的数量–重做日志量越大,完成transaction_backout操作所花费的时间越长。

transaction_backout过程有4个选项。

  • cascade:取消所有事务处理,其中包括依赖的事务处理,这些事务处理在取消父(目标)事务处理之前首先取消。
  • nocascade:没有任何依赖事务处理。默认值。
  • nicascade_force:只取消目标事务处理,忽略依赖事务处理。
  • nonconflict_only:只取消在目标事务处理中不冲突的那些行。

注意:nocascade的默认值期望待取消的事务处理无任何依赖事务处理。

 transaction_backout报告

可用DBA_FLASHBACK_TRANSACTION_STATE和DBA_FLASHBACK_TRANSACTION_REPORT视图检查事务处理取消操作的细节。transaction_backout过程提供这两个视图。如果一个事务处理出现在DBA_FLASHBACK _TRANSACTION_STATE视图中,则意味着该事务处理已经成功取消。对于每个被取消的事务处理,DBA_FLASHBACK_TRANSACTION_REPORT视图提供了详细的报告。 如果不想使用DBMS_FLASHBACK包,还可用 Database Console执行事务处理取消操作。

转发请注明源地址:https://www.askmaclean.com

沪ICP备14014813号

沪公网安备 31010802001379号