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…]

ORA-00600:[15570]内部错误一例

一套Linux上的10.2.0.1系统出现ORA-00600:[15570]内部错误,日志如下:

Sat Jun 5 11:33:17 2010
Memory Notification: Library Cache Object loaded into SGA
Heap size 2190K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
Sat Jun 5 14:57:25 2010
Thread 1 advanced to log sequence 16540
Current log# 3 seq# 16540 mem# 0: /ora_data/mantas/redo03.log
Sat Jun 5 14:58:37 2010
Errors in file /opt/oracle/admin/mantas/udump/mantas_ora_10803.trc:
ORA-00600: internal error code, arguments: [15570], [], [], [], [], [], [], []
Sat Jun 5 14:58:37 2010
Errors in file /opt/oracle/admin/mantas/udump/mantas_ora_10903.trc:
ORA-00600: internal error code, arguments: [15570], [], [], [], [], [], [], []
Sat Jun 5 14:58:39 2010
Errors in file /opt/oracle/admin/mantas/udump/mantas_ora_10801.trc:
ORA-00600: internal error code, arguments: [15570], [], [], [], [], [], [], []

[Read more…]

关于PageRank的一些见解

根据googlepagerankupdate.com的调查,最新的一次PR值更新发生在2010年的4月2日,更早一次则发生在去年圣诞期间也就是2009年的12月31日。相信不少站长都在期盼着PR值更新,Google PageRank预示着一个页面的重要性和相关性,我们需要大量高质量的链接来喂饱它。

很多人大概会很反感看到这一连串PR的计算公式:PR = 0.15 + 0.85 ( PR(Backlink 1)/TotalLinks(Backlink 1) + PR(Backlink 2)/TotalLinks(Backlink 2) + … + PR(Backlink X)/TotalLinks(Backlink X) )。在我眼中PR计算公式并不能说明什么,重点在于你的页面上有什么,其内容是否是独一无二的,是否能给大众带来帮助;实际上越是那些实际内容空洞接近NULL的站点越热衷于提高自身的PR。

在最近SEO业界有着关于PageRank将变得不再可见(invisible)的流言,这源于部分网站坚信PageRank是它们的命根子,是它们生命价值的唯一体现,这一迷信。就我看来这棒极了,很多人大概不再会为了一个数字在别人的网站或博客上制造垃圾评论了。不少SEO方面的公司和专家以PageRank值作为它们成功的标志,显然PR不因该被拿来做炫耀的奢侈品,我们因我们的creation而自豪,绝非因为一个数字。

你大概见到过不少PageRank很低而SERP(search engine results page,如果你不知道这个术语那么不要在乎它,我们要避免陷入一个怪圈)很不错的站点,由此可以证明PageRank并不意味着较高的排名。

SEO没有错,这是一份正当的工作,但SEO真正应该完成的是让我们的页面受到与其内容相符的搜索引擎重视程度,而缔造非某些数字。

11g新动态性能视图V$SQL_MONITOR,V$SQL_PLAN_MONITOR

11g中引入了新的动态性能视图V$SQL_MONITOR,该视图用以显示Oracle监视的SQL语句信息。SQL监视会对那些并行执行或者消耗5秒以上cpu时间或I/O时间的SQL语句自动启动,同时在V$SQL_MONITOR视图中产生一条记录。当SQL语句正在执行,V$SQL_MONITOR视图中的统计信息将被实时刷新,频率为每秒1次。SQL语句执行完成后,监视信息将不会被立即删除,Oracle会保证相关记录保存一分钟(由参数_sqlmon_recycle_time所控制,默认为60s),最终这些记录都会被删除并被重用。这一新的SQL性能监视特性仅在CONTROL_MANAGEMENT_PACK_ACCESS为DIAGNOSTIC+TUNING和STATISTICS_LEVEL为ALL|TYPICAL时被启用。
[Read more…]

试用IE9 Preview

IE 9 Preview版现在可以从http://ie.microsoft.com/testdrive/下载到了:
[Read more…]

11.2.0.2补丁集安装体验

使用了Out-of-place Upgrade方式,安装图形界面沿袭了11.2.0.1的风格:
[Read more…]

滚动游标失效(Rolling Cursor Invalidations)

在Oracle 10g中DBMS_STATS包针对GATHER_TABLE/INDEX_STATS和DELETE_TABLE/INDEX_STATS等收集统计信息的存储过程提供了AUTO_INVALIDATE选项;
该参数允许用户指定是否让那些对统计信息有依存关系的游标失效,举例来说如果SQL游标涉及到的表,索引,列或固有对象的统计信息收到以上存储过程修改时,使用NO_INVALIDATE选项可以指定是否让这些受到影响的游标失效,何时失效。
NO_INVALIDATE选项可以有以下三种值:

  • TRUE : 不让相关游标失效
  • FALSE: 立即让相关游标失效
  • AUTO_INVALIDATE(default):让Oracle自己决定何时让游标失效。
--   no_invalidate - Do not invalide the dependent cursors if set to TRUE.
--      The procedure invalidates the dependent cursors immediately
--      if set to FALSE.
--      Use DBMS_STATS.AUTO_INVALIDATE to have oracle decide when to
--      invalidate dependend cursors. This is the default. The default
--      can be changed using set_param procedure.

当统计信息为DBMS_STATS包所修改,新的尚未在共享池中缓存的游标将直接使用这些统计信息; 对于已经存在的共享池中游标缓存,我们无法在原始子游标的基础上更新它们的执行计划;这些旧的子游标将被新的参考最新统计信息的子游标替代,这个过程包含一次硬解析以便获得新的优化树和执行计划;换而言之传统的立即游标失效(Immediate Cursor Invalidation)就是在统计信息更新后立即导致原始子游标的失效,而我们所说的滚动游标失效(Rolling Cursor Invalidations)是在统计信息成功更新的前提下保证原始子游标不立即失效;设想如果系统中有一张业务相关表,一旦我们更新了该表的统计信息可能导致大量共享失效,短期内硬解析将十分频繁并占用大量cpu,而且很多时候我们并不期望执行计划有显著变化;为了防止dbms_stats包统计信息时不要越帮越忙,就可以考虑到使用NO_INVALIDATE选项。

我们来看看RCI的具体表现:
[Read more…]

Difference between parameter COMPATIBLE and OPTIMIZER_FEATURES_ENABLE

SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> set linesize 200;
SQL> col name for a30;
SQL> col value for a20;

SQL> select name,value
  2    from v$system_parameter
  3   where name in ('compatible', 'optimizer_features_enable');

NAME                           VALUE
------------------------------ --------------------
compatible                     10.2.0.3.0
optimizer_features_enable      10.2.0.4

/* 10.2.0.4升级完毕后compatible参数默认值为10.2.0.3,不同于optimizer_features_enable */

[Read more…]

【分区管理】如何确定分区索引是Global还是Local,PREFIXED 还是NON-PREFIXED

【分区管理】如何确定分区索引是Global还是Local,PREFIXED 还是NON-PREFIXED

 

可以通过 DBA_PART_INDEXES视图中的LOCALITY和ALIGNMENT确定这一点:

LOCALITY VARCHAR2(6) Whether this partitioned index is LOCAL or GLOBAL

ALIGNMENT VARCHAR2(12)   Whether this partitioned index is PREFIXED or NON-PREFIXED

 

CREATE TABLE employees
(employee_id NUMBER(4) NOT NULL,
 last_name VARCHAR2(10), 
 department_id NUMBER(2))
PARTITION BY RANGE (department_id)
(PARTITION employees_part1 VALUES LESS THAN (11) TABLESPACE users, 
 PARTITION employees_part2 VALUES LESS THAN (21) TABLESPACE users, 
 PARTITION employees_part3 VALUES LESS THAN (31) TABLESPACE users);

 CREATE INDEX local_one ON employees (employee_id) LOCAL;

SQL>  CREATE INDEX local_one ON employees (employee_id) LOCAL;

索引已创建。

SQL> select locality,ALIGNMENT from dba_part_indexes where index_name='LOCAL_ONE';

LOCALITY     ALIGNMENT
------------ ------------------------
LOCAL        NON_PREFIXED

drop index LOCAL_ONE;

 CREATE INDEX global_one ON employees(employee_id)
GLOBAL PARTITION BY RANGE(employee_id)
(PARTITION p1 VALUES LESS THAN(5000),
 PARTITION p2 VALUES LESS THAN(MAXVALUE));

SQL> select locality,ALIGNMENT from dba_part_indexes where index_name='GLOBAL_ONE';

LOCALITY     ALIGNMENT
------------ ------------------------
GLOBAL       PREFIXED

 

 

脚本如下:

 

 

select locality,ALIGNMENT from dba_part_indexes where index_name='&INDEX_NAME';

沪ICP备14014813号-2

沪公网安备 31010802001379号