Author: mac

11g默认启用强大的审计选项，AUDIT_TRAIL参数的缺省值为DB，这意为着审计数据将记录在数据库中的AUD$审计字典基表上。Oracle官方宣称默认启用的审计日志不会对绝大多数产品数据库的性能带来过大的负面影响，同时Oracle公司还推荐使用基于OS文件的审计日志记录方式(OS audit trail files)。 注意因为在11g中CREATE SESSION将被作为受审计的权限来被记录，因此当SYSTEM表空间因磁盘空间而无法扩展时将导致这部分审计记录无法生成，这将最终导致普通用户的新会话将无法正常创建，普通用户将无法登陆数据库。在这种场景中仍可以使用SYSDBA身份的用户创建会话，在将审计数据合适备份后删除一部分记录，或者干脆TRUNCATE AUD$都可以解决上述问题。 当AUDIT_TRAIL设置为OS时，审计记录文件将在AUDIT_FILE_DEST参数所指定的目录中生成。全部这些文件均可以随时被删除或复制。 注意在默认情况下会以AUTOEXTEND ON自动扩展选项创建SYSTEM表空间，因此系统表空间在必要情况下还是会自动增长的，我们所需注意的是磁盘上的剩余空间是否能够满足其增长需求，以及数据文件扩展的上限，对于普通的8k smallfile表空间而言单个数据文件的最大尺寸是32G。 以下权限将对所有用户审计: 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 * from global_name; GLOBAL_NAME…

今天在给ASM扩磁盘组的时候发现11.2.0.2上asmcmd中lsdg命令所显示的磁盘组数不正确，现象如下: Node A lsdg正常: ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED EXTERN N 512 4096 1048576 142976 50596 0 50596 0 Y DATA/ MOUNTED EXTERN N 512 4096 1048576 51200 50742 0 50742 0 N FRA/ Node B lsdg仅显示DATA磁盘组 ASMCMD> lsdg State Type Rebal Sector Block…

SMON的作用还包括RAC环境中的Instance Recovery，注意虽然Instance Recovery可以翻做实例恢复，但实际上和我们口头所说的实例恢复是不同的。我们口头语言所说的实例恢复很大程度上是指Crash Recovery崩溃恢复，Instance Recovery与Crash Recovery是存在区别的：针对单实例(single instance)或者RAC中所有节点全部崩溃后的恢复，我们称之为Crash Recovery。而对于RAC中的某一个节点失败，存活节点(surviving instance)试图对失败节点线程上redo做应用的情况，我们称之为Instance Recovery。对于Crash Recovery更多的内容可见<还原真实的cache recovery>一文。 现象 Instance Recovery期间分别存在cache recovery和ges/gcs remaster2个recovery stage,注意这2个舞台的恢复是同时进行的。cache recovery的主角是存活节点上的SMON进程，SMON负责分发redo给slave进程。而实施ges/gcs remaster的是RAC专有进程LMON。 整个Reconfiuration的过程如下图:   注意以上Crash Detected时数据库进入部分可用(Partial Availability)状态，从Freeze Lockdb开始None Availability，到IR applies redo即前滚时转换为Partial Availability，待前滚完成后会实施回滚，但是此时数据库已经进入完全可用(Full Availability)状态了，如下图：   The graphic illustrates the degree of database availability during each step of Oracle instance recovery:  A.         Real Application Clusters is running on multiple…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected] 下载某医院HIS系统Oracle 升级+迁移建议-诗檀软件

如果自己搞不定可以找诗檀软件专业ORACLE数据库团队成员帮您服务! 诗檀软件专业数据库团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected]   项目背景 现状：目前在用的HIS系统由3台P550Q小型机、1台IBM DS4800存储和1台EMC VNX5500存储组成，其中2台P5 550Q运行Oracle 10g RAC环境，另一台P6 550Q（租借）通过Oracle Dataguard实现异地灾备。 问题：HIS系统运行至今已6年多，设备已到生命周期的后期；存储存在单点故障；主机全部部署在门诊楼机房，存在单机房故障风险。  项目目标 消除硬件风险：完成设备更新，消除设备老化带来的故障高发风险。 完善HIS架构：消除存储单点故障，实现高可用和容灾的终极目标。 锻炼HIS运维团队：我院HIS运维团队相对比较年轻，在工作经验、技术水平、项目管理、沟通协作等方面具有很大上升空间，特别是通过大项目的历练，可以加快提高人员素质，对个人、对单位都具有很大好处。  HIS架构完善需求 根据业务分级标准，HIS系统归为Ⅰ级（平均非计划停机时间：99.999%（5分钟）计划停机：1次/季度），系统架构上采用双机房双机双活，灾备模式上采用热备/同步，服务器采用P+P+P小机，在线存储采用2台高端存储，灾备存储采用1台中端存储。 为实现上述目标，本项目需匹配相应的硬件设备和高可用、容灾技术。   数据库需求 2.2.1 数据库容量需求： 支持5年数据库容量 在线数据保留1年半，超出部分做数据转储。 注：目前采用传统的手工转储方式，误操作风险高，费时费力。明年规划引入“自动化数据转储平台”。 2.2.2 数据库版本需求 目前甲骨文公司已经停止对Oracle10g的技术支持。Oracle最新版本为12C，但是市场占有率不高，存在不稳定因素。Oracle11g为市场上较稳定版本，成功案例众多，因此建议升级到Oracle11g。 2.3 操作系统需求 现有AIX版本为5.3，但是IBM公司已经停止对该版本的补丁升级。AIX最新版本为7.1，但是同Oracle12C一样，市场占有率不高。经多方咨询，建议升级到AIX6.1。 1、         架构设计方案 3.1  HIS总体架构设计 为了实现HIS架构完善需求，经过反复论证，最终形成的HIS总体架构如下图所示。   小型机： 两台IBM P740小机分别部署在门诊楼和综合楼机房，通过Oracle RAC计算实现双活及负载均衡。 一台IBM P740小机部署在综合楼机房，利用Oracle Active Dataguard技术实现数据库实时灾备。灾备库部署在医联项目购买的EMC VNX5500存储。…

SMON的作用还包括清理死事务:Recover Dead transaction。当服务进程在提交事务(commit)前就意外终止的话会形成死事务(dead transaction)，PMON进程负责轮询Oracle进程，找出这类意外终止的死进程(dead process)，通知SMON将与该dead process相关的dead transaction回滚清理，并且PMON还负责恢复dead process原本持有的锁和latch。 我们来具体了解dead transaction的恢复过程: 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> select * from global_name; GLOBAL_NAME ——————————————————————————– www.askmac.cn SQL>alter…

oradebug工具是Oracle数据库调优和诊断的利器，合理运用oradebug可以大幅减少我们收集诊断信息所花费的时间。当然前提是合理运用，对于初级DBA有这样一个忠告，不要在生产环境中去接触或修改自己所不熟悉的领域的东西，这一点很重要。并不是说中高级DBA在知识和经验上能达到巨细靡遗的状态，实际上中高级Oracle DBA可能每天都在和新事物打交道。恰恰相反，中高级DBA是对以上忠告最忠实的践行者，在生产环境中绝不随意涉险于不确定、不明确、不熟悉的区域，很多时候这会让人觉得是一种”好奇心丧失”的表现。 言归正传，我们所要介绍的是oradebug的dumpvar命令，该命令用于打印转储固定的PGA/UGA/SGA的变量:，其语法如下: oradebug dumpvar Print/dump a fixed PGA/SGA/UGA variable. Syntax Parameter oradebug dumpvar <p|s|uga> <variable name> [level] <p|s|uga> PGA,SGA or UGA fixed variable name [level] 使用示例 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…

Below is a shell script  which backup dmpfile to ASM storage everyday: #!/bin/bash #asmcmd mkdir DATA/ASM_DATAPUMP_BACKUP #create directory ASM_DATAPUMP_BACKUP as ‘+DATA/ASM_DATAPUMP_BACKUP’; #grant read,write on directory ASM_DATAPUMP_BACKUP to system; #create directory LOGDIR as ‘/s01/logdir’; #grant read,write on directory LOGDIR to system; #create directory DMPBACKUP as ‘/s01/dmpbackup’; #grant read,write on directory DMPBACKUP to system; export ORACLE_HOME=/s01/oracle/product/11.2.0/dbhome_1; export…

在10g中引入了数据泵Data Pump导入导出工具，DataPump的工作流如下图: 我们在使用Data Pump工具时经常会遇到著名的ORA-04031/ORA-04030错误，主要影响DataPump的内存组件有PGA和SGA中的共享池Shared Pool、流池Streams Pool。Expdp/Impdp对shared Pool的开销主要体现在其运行过程中需要调用一系列的包体PACKGE BODY，它们包括: PACKAGE_NAME TYPE SHARABLE_MEM —————————————- ——————– ———— SYS.KUPM$MCP PACKAGE BODY 425448 SYS.KUPW$WORKER PACKAGE BODY 386000 SYS.DBMS_METADATA_INT PACKAGE BODY 325856 SYS.DBMS_REPCAT_UTL PACKAGE BODY 269064 SYS.DBMS_METADATA PACKAGE BODY 226624 SYS.DBMS_DATAPUMP PACKAGE BODY 192888 SYS.DBMS_PRVTAQIS PACKAGE BODY 147288 SYS.DBMS_PRVTAQIM PACKAGE BODY 142680 SYS.KUPF$FILE PACKAGE BODY 142008 SYS.DBMS_METADATA_UTIL PACKAGE BODY 115224 SYS.KUPD$DATA…

上周在客户一套BRM系统上执行分区交换Exchange Partition操作的时候出现了ORA-14098错误，该错误是由于分区表上的LOCAL分区索引与非分区表上的索引不匹配造成的，我们来看一下这个错误: [oracle@rh2 ~]$ oerr ora 14098 14098, 00000, “index mismatch for tables in ALTER TABLE EXCHANGE PARTITION” // *Cause: The two tables specified in the EXCHANGE have indexes which are // not equivalent // *Action: Ensure that the indexes for the two tables have indexes which // follow this rule // For every non…