Author: mac

11g Release1 中引入了新的RMAN duplicate命令，即duplicate from active database命令。利用该命令可以更加便捷地创建Data Guard环境，你甚至不需要将Primary Database shutdown(整个过程中主库都可以处于打开状态下)，也不需要在配置前做一些额外的备份操作，仅需要配置起auxiliary辅助实例，同时创建密码文件，并在监听(LISTENER)中加入静态注册信息后就可以开始工作了！ 以下示例中我们会在Primary Database所在的同一台服务器上部署一套物理备库(Physical Standby)，实际上这样比在不同的2台服务器上配置Data Guard要复杂些，原因是那样的话我们无需做File Name的转换，具体的环境： Database Role DB_UNIQUE_NAME Primary Database PROD Standby Database SBDB   /* 需要注意的是DG环境中force logging,不要用了新特性就将这个基本的要求忘记了 ！ */ 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…

从Oracle 10.1.0.3开始引入了利用逻辑备库(logical standby)实施滚动升级(rolling upgrade)的特性；在滚动升级期间(rolling upgrade)，允许主库(primary database)与逻辑备库(logical standby)间运行不同的数据库版本，以最小化宕机时间。 到了11g中增加了可以将物理备库(physical standby)临时性转换成逻辑备库(logical standby)以完成滚动升级，之后将该临时逻辑备库反转为物理备库的功能。使用以上临时转换功能只需要在转换语句”ALTER DATABASE RECOVER TO LOGICAL STANDBY”后加上”KEEP IDENTITY”选项。除去转换细节的区别外，使用物理备库进行滚动升级的过程与10g中的逻辑备库滚动升级没有太大的区别。 这里我们通过实验来亲身体验一下这一新特性，我们假设环境中存在一套11.1.0.7的Data Guard系统： Database Role DB_UNIQUE_NAME Version Primary Database PROD 11.1.0.7 Physical Standby SBDB2 11.1.0.7 当前的需求是将生产数据库升级到11.2.0.2，但要求最小化应用downtime；这里我们就可以充分利用Data Guard的环境借势升级，同时也不会破坏原有的HA可用性： 1.滚动升级前需要为Primary Database做必要的准备工作，这里如果数据库之前没有启用闪回数据库的话需要enable SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE FLASHBACK ON; SQL> select flashback_on from v$database; FLASHBACK_ON —————— YES SQL> ALTER…

从Oracle 10g以后数据库升级前我们都需要将实例关闭，并以startup upgrade的升级模式启动数据库。那么startup upgrade到底对instance做了什么事？在这样的模式下升级可以绕过那些错误呢？ 就常规判断可以猜测startup upgrade升级模式至少会限制以下几点: 关闭自动作业队列 关闭回收站功能 禁用系统触发器 以限制模式启动，仅允许以SYSDBA身份登录 为了了解更多的细节，我们不妨直观地来观察以下升级模式对比普通模式有哪些不同之处： SQL> startup upgrade; 以升级模式启动后观察告警日志内容: Starting ORACLE instance (normal) 以上信息表明虽然是upgrde模式，但其实仍是以NORMAL启动 ……….. ALTER SYSTEM enable restricted session; 实例mount之后启用了限制会话特性 ALTER SYSTEM SET _system_trig_enabled=FALSE SCOPE=MEMORY; _system_trig_enabled参数控制一些系统触发器是否被启用，例如某些登录审计触发器 (system trigger facilities are used as an additional audit trail or as a mechanism to prevent certain actions taking place or as…

Sql Tuning Advisor是10g以后出现的一个十分有用的调优工具，大多数情况下我们可以通过dbconsole或者Grid Control的web界面调用SQL Advisor；但如果系统中没有配置dbconsole或者Grid Control的话，我们则需要通过手动调用DBMS_SQLTUNE PL/SQL程序包来使用该特性。这里我列出一个针对单个SQL语句Autotune的脚本，具体脚本: begin DBMS_SQLTUNE.drop_tuning_task(‘&task_name’); end; / DECLARE my_task_name VARCHAR2(30); my_sqltext CLOB; my_sqlid varchar2(30); BEGIN my_sqlid := ‘&sqlid’; my_task_name := dbms_sqltune.create_tuning_task(sql_id => my_sqlid, scope => ‘COMPREHENSIVE’, time_limit => 300, task_name => ‘&task_name’, description => ‘comment’ ); END; / BEGIN dbms_sqltune.execute_tuning_task(task_name => ‘&task_name’); END; / SELECT status FROM USER_ADVISOR_TASKS WHERE task_name =…

一套Sparc Solaris上的10.2.0.1数据库，告警日志中出现ORA-07445:[_memcmp()+88] [SIGSEGV]内部错误日志，具体日志如下: Errors in file /global/oracle1/centDB/admin/centDB/udump/centdb_ora_8749.trc: ORA-07445: exception encountered: core dump [_memcmp()+88] [SIGSEGV] [Address not mapped to object] [0x000000010] [] /global/oracle1/centDB/admin/centDB/udump/centdb_ora_8749.trc Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production With the Partitioning, OLAP and Data Mining options ORACLE_HOME = /global/oracle1/ORAHOME1/product/10.2/db_1 System name: SunOS Node name: ora03ud-us Release: 5.10 Version: Generic_142900-13 Machine: sun4u…

OEM或者OMS管理工具为我们提供了方便的访问数据库度量告警和错误信息的界面，那么我们是否可以通过手动查询的方式来直接查看这些信息呢？答案是肯定的，这需要我们对OMS repository有一定的了解: SQL> desc sysman.MGMT_CURRENT_METRIC_ERRORS; Name Null? Type —————————————– ——– —————————- TARGET_GUID NOT NULL RAW(16) METRIC_GUID NOT NULL RAW(16) COLL_NAME NOT NULL VARCHAR2(64) AGENT_GUID NOT NULL RAW(16) COLLECTION_TIMESTAMP NOT NULL DATE METRIC_ERROR_MESSAGE VARCHAR2(4000) METRIC_ERROR_TYPE NUMBER(1) /* MGMT_CURRENT_METRIC_ERRORS记录了当前出现在OMS console中的度量错误记录 */ SQL> desc sysman.MGMT_METRIC_ERRORS; Name Null? Type —————————————– ——– —————————- TARGET_GUID NOT NULL RAW(16) METRIC_GUID NOT NULL…

Oracle最近宣布将停止其所有在Intel Itanium平台上的软件开发，将更加专注于X86和Sparc平台。换而言之我们肯定不会看到ia64版本的Oracle Database 12g了，但是否会就现有版本的Itanium平台软件继续发布补丁集则仍是一个未知之数。 这是继Microsoft和Redhat后又一重量级的厂商为安腾平台敲响喪鐘，很显然这是墙倒众人推，Intel Itanium气数已尽。

今天上午接到电话，用户反映一套10.2.0.4的数据库出现用户无法登录的症状，随即在家里连上VPN远程支持，登上主机以后尝试测试操作系统认证登录和远程登录，发现已经能够正常登录了；为了了解起因，去查看了告警日志alert.log，发现在11:00左右出现大量的ksvcreate:process creation failed错误，具体错误日志如下: Wed Mar 23 10:00:17 2011 Process m000 died, see its trace file Wed Mar 23 10:00:17 2011 ksvcreate: Process(m000) creation failed Wed Mar 23 10:01:18 2011 Process m000 died, see its trace file Wed Mar 23 10:01:18 2011 ksvcreate: Process(m000) creation failed Wed Mar 23 10:02:19 2011 Process m000 died, see its…

一套Linux上的11.1.0.7的physical standby物理备库在使用fast incremental backup进行高于0级的增量备份时会出现ORA-19648错误，其出错记录如下： RMAN> backup incremental level 1 database; Starting backup at 22-MAR-11 using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting incremental level 1 datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00002 name=/standby/oradata/SBDB2/datafile/o1_mf_sysaux_22m6ov92_.dbf input datafile file number=00003 name=/standby/oradata/SBDB2/datafile/o1_mf_undotbs1_23m6ovap_.dbf input datafile file number=00006 name=/standby/oradata/SBDB2/datafile/o1_mf_enc_25m6ovba_.dbf channel ORA_DISK_1: starting piece…

在10g以后我们可以通过利用gather_plan_statistics提示来了解更多的SQL执行统计信息，具体使用方法如下： SQL> set linesize 150 SQL> set pagesize 2000 SQL> set autotrace traceonly exp SQL> select avg(SALARY),DEPARTMENT_NAME from employees e,departments d where e.DEPARTMENT_ID=d.DEPARTMENT_ID group by DEPARTMENT_NAME; Execution Plan ———————————————————- Plan hash value: 3294250112 ——————————————————————————————— | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ——————————————————————————————— | 0 | SELECT STATEMENT…