下午4点半，rems2发出cpu负载高的警报——使用率超过50%。不是演习、不是测试，真正的核心系统：两台aix上的一套Oracle 10g RAC。 很明显16:30之后，cpu负载上升，一直到17:00，使用率在50%处波动～ 同时网络流量，内存，交换分区都很平稳： 检查数据库对应时段的指标，逻辑IO明显的高阶运行，激活会话数升到35左右，物理IO与用户调用无对应跳阶： 接下来，很自然的就是Top Session显示，Top SQL分析了～ 很遗憾，咱是生产核心系统，这些都不允许贴出来了😄 好的监控、性能分析工具，随着你的心意、方向，有如低扭强大的机械马达——让你御风而行
有几种方法来编写’case insensitive’的SQL语句——SQL需要避免全表扫描。如果是Oracle10g R2之前版本，我们需要：1. 在查询中转换数据，使其大小写不敏感（case insensitive）,FBI(Function Base Index)： create index upper_full_name on customer ( upper(full_name)); select full_name from customer where upper(full_name) = ‘SAM HENDRY’;2. 在存储数据（insert或者update）时，使用触发器完成case insensitive转换（比如使用to_lower,to_upper 内建函数）。3. 使用 alter session命令 alter session set NLS_COMP=ANSI; alter session set NLS_SORT=GENERIC_BASELETTER; select * from customer where full_name = ‘Sam Hendry' 在Oracle 10g R2版本中，引入了使用BINARY_CI BINARY_AI排序来进行case insensitive查询的功能。 初始化参数设置： NLS_SORT=binary_ci NLS_COMP=ansi 创建索引：
Latch等待应该说并不是一件坏事情。毕竟，设计Latch的目的就是用来让你等待的。Oracle使用Latch来保护SGA区中的关键数据结构不会在一个进程正在访问、修改时被另外一个进程访问，避免SGA区关键数据结构出现Corruption。暂时的waiting要比内存corruption更让人接受，不是么？不过，如果经常性的出现两个或多个进程等待同一个Latch，这就是一个问题了。因为，当Latch被释放（free）时，正在等待此Latch的多个进程将争抢Latch的所有权，而且只能有一个进程如愿获得Latch的所有权；而其他参与争抢的进程将消耗无效的CPU时间去spin、wait。随着参与争抢Latch的进程数量增加，将会造成严重的性能问题；而如果这个问题能够得到解决，这个性能问题会迅速的消失。一般来讲，共有三种不同的latch争用问题：1. 高CPU占用可能会触发latch争用问题。试想，如果一个已经获得latch所有权的进程不能迅速的获得CPU使用时间片，对这个latch的大量等待当然就不可避免了。为了避免由于CPU饥饿（CPU starvation）造成的latch争用问题，你应该保证你的系统不会持续较长时间的出现CPU占用率超过85％的压力高峰（当然，在某些系统中高CPU使用率是安全的）。很多系统问题（check for run-away process、paging）都会造成CPU的过度使用，所以说，在诊断一个Oracle性能问题的时候，你应该首先确保他确实是Oracle问题——而不是OS操作系统问题。2. Oracle预期latch被间断的、简短的占用。一些Latch争用性能问题的出现恰恰是因为一个Latch被超出预期的长时间占用。这种类型的问题通常是由于SGA区中的某个访问受latch保护的链表增长的太长（比如Shared Pool的碎片太多、buffer cache中的hash chains太长等等）。 这种类型的latch争用问题对_spin_count初始化参数的设置非常敏感。如果spin循环的时间恰恰短于这种类型的latch能够被获取的时间，这时尝试获取latch的进程就会停止spin，转入sleep状态；这种情况下，如果适当增加_spin_cout参数，使得spin循环的时间能够赶上占用Latch进程释放latch的时间，就可以避免进程sleep。当然，最好的调节方法是减少latch占用的时间，而不是增加latch spin的时间。3. Latch争用的性能问题也可能并不是由于Latch hold时间太长，而仅仅是因为获取Latch占用权的请求太过频繁了。最典型的一个例子是因为commit太过频繁而造成的’redo allocation’latch的争用。 这种情况下，最好的解决办法当然是避免太过频繁的latch request；但是很多情况下，最有效的解决方案也是最不可能的方案。通常，我们可以通过增加相应的child latch数量来缓解这个问题（比如 cache buffer lru latch），增加_spin_count对这种类型的性能问题没有帮助。如果我们不能降低latch request的频率（比如修改应用commit的频率），而且这个latch也不属于默认的long latch类别（默认好像只有两个latch是long latch： shared pool 、library cache）；因为long latch默认支持latch posting特性，我们可以通过设置初始化参数_latch_wait_posting为2来强制对所有的latch类型都支持latch wait posting。 ——对于这一点，我心存疑虑，latch wait posting毫无疑问对某些latch会有负面影响，或者会过多的消耗资源；不然Oracle为什么只默认支持shared pool、libarary cache的wait posting呢；所以除非十分必要且经过测试，这种手段还是谨慎使用了。很显然的，要想恰当的解决latch争用造成的性能问题，首先我们得判断它是属于哪种类型的latch争用。以上3中类型中，CPU starvation应该是最容易判断的；其他两种类型的latch可以通过v$latch_misses加以区分。这个视图中包含了request或者hold每一个latch对应的Oracle Kernel位置。SQL> desc v$latch_misses Name Null? Type ----------------------------------------- -------- ---------------------------- PARENT_NAME VARCHAR2(50) WHERE VARCHAR2(64) NWFAIL_COUNT NUMBER
背景： **保险核心业务系统数据库使用Oracle 10.2.0.5 版本 RAC（Real Application Cluster）集群，集群构建在IBM Aix系统上，包含两个节点：【node1，node2】。 在较长一段时间内，node2会每间隔20天左右，出现ORA-04031错误，导致该节点数据库系统不再可用，需重启该节点上Oracle 实例方能解决问题。 ORA-04031错误解释： 04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"// *Cause: More shared memory is needed than was allocated in the shared// pool or Streams pool.// *Action: If the shared pool is out of memory, either use the// DBMS_SHARED_POOL package to pin large
Oracle数据库细粒度审计（Fine-Grained-Audit）应用 设计目标： 在实际的业务场景中，经常有审计“某人、某时间段、查看了某条敏感数据”这样的需求，Oracle本身提供了DB Vault、Audit Vault组件。 本文讨论使用细粒度审计，实现医院“防统方”功能： 背景： 医生开药后会从对应厂商医药代表处收取回扣，而收取回扣，需要统计处方中的药品、数量、医生信息。现阶段“纪委”部门严禁“统方”——对处方用药进行统计——操作。 期望实现对“可疑操作”的审计记录功能，后续对“可疑”记录进行进一步分析，进而准确确认是否为“统方”操作。 所以，技术实现上分两个阶段： 可疑操作记录 可疑操作分析架构设计应具备可扩展性： 规则可定义 能够适用其他“敏感数据”审计需求 阶段一： 可疑操作记录 概述： 通过Oracle FGA，记录可疑操作。 FGA技术背景： DBMS_FGA.ADD_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2, audit_condition VARCHAR2, audit_column VARCHAR2, handler_schema VARCHAR2, handler_module VARCHAR2, enable BOOLEAN, statement_types VARCHAR2, audit_trail BINARY_INTEGER IN DEFAULT, audit_column_opts BINARY_INTEGER IN DEFAULT); Oracle FGA核心的操作就是这个存储过程的调用： 我们需要指定object_schema, object_name来限定是对哪个表（对象）来做审计；使用audit_condition（SQL 逻辑表达式，但是有一定限制，如不能使用子查询，不能使用rownum伪列等）来限制“行”级别的敏感数据——只有符合此条件的，才触发审计操作。使用audit_column来指定“敏感”列，只有涉及敏感列的操作才被审计，结合audit_column_opts，灵活定义敏感列（其实就是Any还是All的关系）audit_trail来指定审计结果存放的“位置”，也决定审计记录的数据内容（特别是是否记录SQL，以及绑定变量），这里最需要特别指出的是，这里的设置不依赖于数据库级别的audit_trail 初始化参数。handler_schema 和 handler_module指定“敏感”操作发生时，调用的存储过程，用来自定义一些处理操作。
Declare v_BaselineSize number(20); v_CurrentSize number(20); v_TotalGrowth number(20); v_Space number(20); cursor usageHist is select a.snap_id, SNAP_TIME, sum(TOTAL_SPACE_ALLOCATED_DELTA) over ( order by a.SNAP_ID) ProgSum from (select SNAP_ID, sum(SPACE_ALLOCATED_DELTA) TOTAL_SPACE_ALLOCATED_DELTA from DBA_HIST_SEG_STAT group by SNAP_ID having sum(SPACE_ALLOCATED_TOTAL) <> 0 order by 1 ) a, (select distinct SNAP_ID, to_char(END_INTERVAL_TIME,'DD-Mon-YYYY HH24:Mi') SNAP_TIME from DBA_HIST_SNAPSHOT) b where a.snap_id=b.snap_id;Begin select sum(SPACE_ALLOCATED_DELTA) into v_TotalGrowth from DBA_HIST_SEG_STAT; select sum(bytes) into v_CurrentSize from dba_segments; v_BaselineSize := v_CurrentSize - v_TotalGrowth ; dbms_output.put_line('SNAP_TIME Database Size(MB)'); for row in usageHist loop v_Space := (v_BaselineSize + row.ProgSum)/(1024*1024); dbms_output.put_line(row.SNAP_TIME || ' ' || to_char(v_Space) ); end loop;end;
查询Oracle归档日志产生频率，以日历形式展现：. SELECT * FROM (SELECT A.*, B.SIZE_GB, DECODE(C.SIZE_GB, NULL, 0, C.SIZE_GB) DELETED_GB, B.SIZE_GB - DECODE(C.SIZE_GB, NULL, 0, C.SIZE_GB) REMAIN_GB FROM (SELECT * FROM (SELECT TO_DATE(b.date_time, 'DD/MM/YYYY') dt, TO_CHAR(TO_DATE(b.date_time, 'DD/MM/YYYY'), 'DAY') DAY, "00", "01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23",
Summary As a DBA you may need to log in as another user, for example to test an application after doing some workarounds to solve a problem. But you don't know the password and you don't want to wait. You can change the password, as dba, but how to change it back to previous? The right way
问题描述 应用人员报障说每月都在执行的一个sql今天突然怎么也执行不下去，并报如下错误： ORA-00600: internal error code, arguments: [32695], [hash aggregation can't be done], [], [], [], [], [], [] 操作系统为SUNOS 5.10，Oracle版本为：10.2.0.4.0，单机环境 执行的SQL语句为： INSERT INTO MID_DM_RPT_COMP_SUB_PROD_M SELECT COMP_AREA_ID, COMP_CITY_ID.....省略.... 经查询mos并找到如下文档ORA-600 [32695] [hash aggregation can't be done] (文档 ID 729447.1) 该文档给出的解决办法如下： 禁用hash group by SQL> alter system set "_gby_hash_aggregation_enabled"=false scope=spfile; SQL> alter session set "_gby_hash_aggregation_enabled"=false; 通过在SQL语句中添加hint NO_USE_HASH_AGGREGATION绕过bug
系统环境 OS:SUNOS 5.10 DB:Oracle 10.2.0.4.0 问题现象 用户在pl/sql developer上执行insert select 语句报报ORA-32690，如图： 问题分析 根据文档（Query crash with ORA-32690 -- Bug 6471770. (文档 ID 960690.1)）得知，该问题是由于Bug 6471770所致。 Bug 6471770影响的版本：10.2.0.3.0及之后的版本，并在11.2中被修复。 MOS上给出的解决办法： Cause This seems to be Bug 6471770. - Known bug on database version 10.2.0.3. - The workaround is resolving the issue. The bug is fixed in 11.2 release. Solution: So