ITPub博客

本想将windows 下oracle表空间传输到RAC linux上但windows oracle字符集是ZHS16GBK, 而linux oracle 字符信是AL32UTF8于时先将windows下字符集转换成AL32UTF8SQL> select userenv('language') from dual;USERENV(...

About Oracle Hanganalyze 1. 数据库hang的几种可能性oracle死锁或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住，比如大量的DX锁。通常来说，我们所指的系统hang住，是指应用无响应，普通的sqlplus几乎无法操作等等。2. 如何进行hang分析？hang分析有哪些level？如何...

ORA-03297

近期几次停一个库迁文件时, 发现srvctl stop instance xxx 停库后, 迁完文件在open时报SQL> alter database open;alter database open*ERROR at line 1:ORA-01122: database file 113 failed verification checkORA-...

mutex是11g中采用的轻量级锁，替代latch(更轻量，更细粒度)。其中mutex X表示eXclusive模式，如果是mutex s则是共享模式。引起library cache mutex冲突的原因很多。[@more@]一、 Library cache: mutex等待事件产生常见原因：l os资源不足(cpu、内存)l sga设置不合理，shared_pool不足，或动态调整导致hard parsel hot object contentionl hard parsel sql high version count 由于子游标太多，扫描时会形成锁l library cache object失效导致重编译l bug二、 诊断方法1. 首先检查os资源如cpu内存是否存在不足2. 其次，检查是否存在Hot obje

-- 查询隐含参数 select ksppinm, ksppstvl from x$ksppi pi, x$ksppcv cv where cv.indx = pi.indx and pi.ksppinm like '_undo_autotune%' 可以看到默认是true . SQL> ALTER SESSION SET NLS_DATE_FORMAT='YYYY/MM/DD HH24:MI:SS' ; Session altered.v$undostat中查看调整优化后的undo_retention (tuned_undoretention)....

Undo一个重要用途就是在对数据进行修改时候，能将数据块中被修改前的数据(注意不是数据块，一般被称为before image)保存到回滚段中。回滚时就可以取出还原。 UNDO还有其他用途，如一致性读、闪回功能(Flashb...

    客户的数据库是Oracle Database 11.2.0.3.0 for AIX 6.1 64bit的单机数据库。客户查询DBA_FREE_SPACE发现UNDO表空间的使用率高达98%以上。客户的UNDO表空间已经手动扩展到了25GB，且一直在增加，为了UNDO表空间能及时的被释放，UNDO表空间对应的所有数据文件自动扩展都被关闭。查询DBA_UNDO_EXTENTS发现在UN...

ora04030

        公司有个项目的数据库有几张大表，每张表都是几亿条数据，之前一直未做分区，随着数据量的不断增大，维护越发困难，为了更好的管理这些表数据，决定为这些大表做分区表...

dbms_stats收集统计信息时候no_invalidate参数用于是否与收集相关object的cursor失效，defalut(9i false, 10g dbms_stats.auto_invalidate(既null))true：当收集完统计信息后，收集对象的cursor不会失效（不会产生新...

常用分析sql语句： --子查询中 request>0 即是存在锁请求的会话，通过 id1, id2, type 关联 gv$lock，即可将阻塞者和被阻塞者全部列出；select /* +rule*/t.INST_ID,decode(request,0,'holder','waiter') role,t.SID,t.TYPE,t.REQUEST,t.LMODE,t.BLOCK,t.CTIME,t.ID1,t.ID2 from  gv$lock t w...

在数据库的日常学习中，发现公司生产数据库的默认临时表空间temp使用情况达到了30G，使用率达到了100%； 待调整为32G后，使用率还是为100%，导致磁盘空间使用紧张。根据临时表空间的主要是对临时数据进行排序和缓存临时数据等特性，待重启数据库后， temp会自动释放。于是想通过重启数据库的方式来缓解这种情况，但是重启...

环境描述： 操作系统 redhatlinux 5.8 数据库版本 oracle 11.2.0.1 单实例状况信息：   由于本实例属于外围小系统并没有对其 文件系统，数据库实例等状态进行监控，故导致文件系统满了 导致实例挂起；处理过程：      1. 经过查看alter 日志：如下文标红部分 文件系统无空...

今天遇到了这个情况，然后在网上找了到了这篇文章，借鉴过来做参考吧！ 1.查看是哪一个存储过程被锁住查V$DB_OBJECT_CACHE视图select * from V$DB_OBJECT_CACHE where owner='过程的所属用户' AND LOCKS!='0'2.查看是哪一个sid，通过sid可以知道是哪一个session查v$access视图select * from v$access where ...

【性能调优】Oracle AWR报告指标全解析2013/08/31 BY MACLEAN LIU 26条评论【性能调优】Oracle AWR报告指标全解析开Oracle调优鹰眼，深入理解AWR性能报告：http://www.askmaclean.com/archives/awr-hawk-eyes-training.html开Oracle调优鹰眼，深入理解AWR性能报...

inst_id分区避免rac gc buffer busy 通过ASH报告，我看到刚才系统HANG住的时候，主要的等待事件是buffer busy wait： Avg Active Event Event Class % Activity Sessions ----------------------------------- --------------- ---------- ---------- buffer busy waits Concurrency 72.55 9.31 enq: HW - contention Configuration 14.21 1.82 gc buffer busy Cluster 7.67 0.98 CPU + Wait for CPU CPU 2.13 0.27 ------------------------------------------------------------- 看样子是由于热块冲突导致系统HANG住的，而且高水位推进

    数据块在buffer cache存放是以linked list方式存放的。当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中，检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的。要判断block是否存在于buffer cache中，就需要扫描linked list(此...

在我的一个两节点RAC数据库上，alert日志中平均每3秒左右就会产生一条ORA-3136连接超时错误，登录数据库之后，检查会话的等待事件，发现很多会话的event为library cache lock，并且发现由于library cache lock造成锁阻塞的会话也很多，从AWR报告的Time Model Statistics部分可以看到，connection management call 消耗的时间占整个DB Time的99.95%，记得以前好象看到过由于11g的新特性密码错误可能造成大量library cache lock的文章，于是上MOS上也查了查相关的文档，结合dba_audit_trail视图发现，从4月7日起到现在，平均每天约有九千多次的登录失败记录，那么是不是4月7日对PAMPAS_W用户更改密码了呢？ 通过查询sys.user$也得到了验证，用户在4月7日9点31分更改过密码。到此问题查清了，解决方案也很简单，通知负责应用的工程师来改正密码或者在数据库层面也可通过设置28401事件来屏蔽密码错误验证延迟功能。 oracle采用的这种密码延

??有一套10.2.0.4两节点RAC数据库，大概每隔一星期左右，后台alert就会报临时表空间不足的错误，通过查询发现占用监时表空间的sql是在执行一个包体，该包体已被加密，并且之前该库的临时表空间已经扩展过2次，每次30G，基本上可以说，既使再扩展的话还是有可能造成临时表空间不足的情况，带着这个问题，我们发现占用大量监时表空间的数据类型为LOB_DATA和LOB_INDEX，每个会话占用的临时段大小不一，最大的可能占用到几十G以上，并且还会持续增长，这说明会话占用的临时段一直不释放，积累造成临时表空间满。通过网上搜索及查询MOS文档,觉得可能是ORCLE的bug(Bug 5723140 – Temp LOB space not released after commit [ID 5723140.8]),从10.2.0.4开始虽然已经修复了该bug,但是默认情况下:为了更加高效的利用temp,在session未断开前,不自动释放temp 空间,可以通过设置event 60025来强制会话在commit之后就立即释放临时段。