标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,884)
- DB2 (22)
- MySQL (82)
- Oracle (1,709)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (73)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录19c ASM磁盘掉线触发ORA-59048故障处理
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
分类目录归档:数据库
inactive transaction branch等待事件
分析一份awr,发现不太熟悉的等待事件”inactive transaction branch”,awr相关信息如下



分析top 1 sql中的对象
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 IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
SQL> select owner,object_type from dba_objects where object_name =upper('wCommonShortMsg');
OWNER OBJECT_TYPE
------------------------------ -------------------
PUBLIC SYNONYM
OFFONQUERY SYNONYM
SQL> COL DB_LINK FOR A12
SQL> select TABLE_OWNER,TABLE_NAME,DB_LINK from dba_SYNONYMS WHERE
2 SYNONYM_NAME=upper('wCommonShortMsg');
TABLE_OWNER TABLE_NAME DB_LINK
------------------------------ ------------------------------ ------------
WCOMMONSHORTMSG CRMDB_LINK
WCOMMONSHORTMSG DB_LINK_CRM
通过这里查询,可以确定引起dblink相关等待严重的是关于wCommonShortMsg同义词查询导致(使用dblink连接到其他库),结合数据库版本,大致可以确定inactive transaction branch等待和MOS中的bug 10413418相符

发表在 Oracle性能优化
3 条评论
记录一次AIX 4.3.0+ORACLE 8.0.5恢复过程
最近接手一个AIX下面ORACLE 8.0.5恢复需求.这个需求要从2个月前说起.2个月前有客户提出需求,帮他们恢复8.0.5的库(该库被9.2.0.4的ORACLE强制拉过,但是未成功).当我准备去恢复的时候,客户和我说数据库的存储找不到了,暂时不用处理.本来这个事情到此也就算结束了,最多算一个笑话(找人数据库恢复,发现数据库丢了).前几天又接到关于这个恢复的请求,说他们还有磁带的备份(备份方式:begin tablespace backup+cp+archivelog),让我去协助恢复.按照客户的描述,他们购买了国外的读磁带机器可以读取磁带到硬盘,他们解压好数据文件,然后我去恢复,而且数据文件,控制文件,归档日志都存在.我当时认为这个是一个简单的恢复,顺利的话,一个小时就可以搞定.这里告诉我们:哪怕是N久的备份,也可能是最后的救命数据(2004年的磁带备份),一定要做好备份
今天到达现场,客户第一句话:文件没有解压,第二句话:归档日志没有恢复出来.听到这里,我有点感觉情况很不妙.
详细一问:文件没有解压是因为AIX 4.3.0默认的是文件系统格式是jfs,最大支持lv的大小为20g(估计和客户参数有关系),现在如果解压需要分到多个目录中(数据库原始运行就是按照该模式进行的,如:oradata001,oradata002等分别放几个数据文件),需要我去给他们做规划,如果存放这些文件.大脑一晕,dba原来真的什么活都要干啊.本身就对AIX不熟悉,还要去想办法处理这些问题,而且是从来没有见过的AIX 4.3.0.最后通过我和客户的一起努力终于解决了这个问题:使用其他技巧在AIX 4.3中建立jfs2文件系统(先划分小的LV,使用jfs系统,然后修改系统为jfs2,然后增加lv大小),解决以前jfs文件系统限制,解压的时候需要规划文件目录的体力活.这个问题告诉我们:有时候解决问题需要学会变通
归档日志没有恢复出来的原因:因为连续几天的恢复,加上客户本身工作繁忙,可能实在是太累,在最后一盘磁带的恢复的时候(一盘磁带15小时,一共4盘),客户敲错了命令tar -xvf输入成了-cvf,使得磁盘头被覆盖,磁带原则上报废,从而使得归档日志无法恢复出来.这一点点的事故告诉我们:越疲劳越容易出错,越到最后越容易出错,一定要小心谨慎
到这一步,没有解压(已经解决文件系统问题,接下来的解压问题不大),没有归档(修改scn原则上可以解决),这些东西总的来说问题都不大,当我安装好AIX FOR ORACLE 8.0.5,启动数据库到mount状态,核对恢复出来的数据文件和控制文件中的数据文件的时候,发现少了好几个,这下不能容忍了(能够open库,但是可能丢失需要数据,这个太不划算[因为用户还有该备份的前几天的备份]),寻找出现数据文件从磁带中丢失原因:1.因为jfs文件系统限制,不停的mv到其他目录导致丢失.2.uncompress解压丢失.3.最后一盘磁带损坏导致丢失.一切原因都是浮云,解决了jfs2文件系统,客户根据当前的情况,决定使用其他的备份再次从磁带中导出,然后进行恢复
AIX 4.3安装ORACLE 8.0.5
--检查内存 lsattr -El sys0 -a realmem --检查交换分区 lsps -a --检查临时目录 df -k /tmp --检查操作系统位数 getconf HARDWARE_BITMODE bootinfo -y --检查操作系统版本号 oslevel -r --检查软件包 lslpp -l bos.adt.base, bos.adt.libm --检查补丁包 instfix -i | grep IX71948 --升级aix smit install_latest smit update_all 增加用户: useradd oracle 增加组: mkgrp dba 更改用户所属组: usermod -g dba oracle 更改用户密码: passwd oracle pwdadm oracle --关于用户 smit mkuser 建立用户 smit lsuser 列出所有用户的属性 lsuser ALL smit chuser 改变用户属性 rmuser -p * 删除用户* smit rmuser 只删除用户,但是不删除所属目录,等于rmuser smit passwd 修改密码 smit lockuser 给用户加锁 --关于用户组 smit mkgroup 建立新组 smit lsgroup 显示所有组的属性 smit chgroup 修改组的属性 smit rmgroup 删除*组 rmgroup * 配置shell limits( smit chuser) soft FILE size -1 soft CPU time -1 soft DATA segment -1 soft STACK size -1 新建目录: mkdir /u01 更改目录属主: chown oracle /u01 更改目录所属组: chgrp dba /u01 vi /home/oracle/.profile export LINK_CNTRL=L_PTHREADS_D7 export NLS_LANG=american_america.zhs16cgb231280 export ORACLE_OWNER=oracle export ORACLE_TERM=vt100 #export ORACLE_TERM=xterm export ORACLE_BASE=/oracle export ORACLE_HOME=$ORACLE_BASE/product/8.0.5 export ORACLE_SID=ora8 export LD_LIBRARY_PATH=$/ORACLE_HOME/lib:$LD_LIBRARY_PATH export LIBPATH=$ORACLE_HOME/lib:$LIBPATH export ORA_NLS32=$ORACLE_HOME/ocommon/nls/admin/data export PATH=$ORACLE_HOME/bin:$PATH export TMPDIR=/tmp export DISPLAY=172.100.1.2:0.0 set -o vi umask 022 --Mount产品光盘 $ su root -查看光驱 $ lsdev -Cc cdrom # mkdir /cdrom # chmod 777 /cdrom # /etc/mount -rv cdrfs /dev/cd0 /cdrom # exit --运行rootpre.sh脚本。 $ su root # cd /cdrom/orainst # ./rootpre.sh # exit --运行安装程序 $ cd /cdrom/orainst -图形 $ ./orainst /m -字符 $ ./orainst /c # cd $ORACLE_HOME/orainst # ./root.sh
建立密码文件
cd $ORACLE_HOME/dbs orapwd file=orapw$ORACLE_SID password=oracle
创建pfile文件
vi $ORACLE_HOME/dbs/init.ora db_name=ORCL db_files = 5000 control_files = /oradata/ctl1ORCL.ora db_file_multiblock_read_count = 8 db_block_buffers = 100000 shared_pool_size = 115343360 log_checkpoint_interval = 10000 processes = 590 parallel_max_servers = 5 log_buffer = 163840 sequence_cache_entries = 100 sequence_cache_hash_buckets = 90 max_dump_file_size = 102400 global_names = TRUE background_dump_dest=/oracle/trace user_dump_dest=/oracle/trace db_block_size = 4196 remote_login_passwordfile = shared text_enable = TRUE job_queue_processes = 2 job_queue_interval = 10 job_queue_keep_connections = false distributed_lock_timeout = 300 distributed_transactions = 5 open_links = 4
操作8.0.5数据库
--结果测试与win,linux/unix使用svrmgrl命令 C:\oracle\ora80\BIN>SVRMGR30.EXE Oracle Server Manager Release 3.0.5.0.0 - Production (c) Copyright 1997, Oracle Corporation. All Rights Reserved. Oracle8 Release 8.0.5.0.0 - Production PL/SQL Release 8.0.5.0.0 - Production SVRMGR> connect system/manager Connected. SVRMGR> select * from v$version; BANNER ---------------------------------------------------------------- Oracle8 Release 8.0.5.0.0 - Production PL/SQL Release 8.0.5.0.0 - Production CORE Version 4.0.5.0.0 - Production TNS for 32-bit Windows: Version 8.0.5.0.0 - Production NLSRTL Version 3.3.2.0.0 - Production 5 rows selected. SVRMGR> connect internal/oracle Connected. SVRMGR> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination %RDBMS80%\ Oldest online log sequence 3 Current log sequence 6 SVRMGR> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SVRMGR> startup mount; ORACLE instance started. Total System Global Area 15077376 bytes Fixed Size 49152 bytes Variable Size 12906496 bytes Database Buffers 2048000 bytes Redo Buffers 73728 bytes Database mounted. SVRMGR> alter database archivelog; Statement processed. SVRMGR> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination C:\oracle\ora80\RDBMS80\ Oldest online log sequence 3 Next log sequence to archive 6 Current log sequence 6
发表在 Oracle备份恢复
一条评论
通过awr指标评估会话建立是否频繁
有朋友问我,通过awr怎么来判断系统这个时间段的会话建立情况,也就是说如果中间件或者客户端程序发生异常,过多的连接数据库.
我这里有个例子,用户的数据库大概在每秒钟建立10个连接左右(相对而言比较频繁)
[oracle@xifenfei tmp]$ grep "18-JUL-2012 18:40:03" listener.log |wc -l 9 [oracle@xifenfei tmp]$ grep "18-JUL-2012 18:40:04" listener.log |wc -l 7 [oracle@xifenfei tmp]$ grep "18-JUL-2012 18:41:04" listener.log |wc -l 12 [oracle@xifenfei tmp]$ grep "18-JUL-2012 18:40" listener.log |wc -l 554 [oracle@xifenfei tmp]$ grep "18-JUL-2012 18:50" listener.log |wc -l 598 [oracle@xifenfei tmp]$ grep "18-JUL-2012 19:00" listener.log |wc -l 597
我们分析这个时间段的awr,看那些地方是可以表明用户会话建立频繁
awr汇总信息
通过这个信息我们可以发现awr报告时间段(120分钟),和数据库在起点和终点的会话数
说明:该数据库问题很多,出现负载高,不全是会话建立频繁导致,这里只分析建立会话相关情况

Load Profile信息
通过这里的Logons为36对于这样的系统来说,明显异常

Top 5 Timed Events
这里的latch: session allocation等待就是比较明显的建立会话时候出现的等待

Time Model Statistics
Time Model Statistics中的connection management call elapsed time大家都明白的,建立会话花费时间

Dictionary Cache Stats
dc_usernames和dc_users请求值偏大

总结说明
在实际工作中:遇到过因为session建立太频繁导致监听繁忙,tnsping延迟比较严重案例,也遇到因为会话建立频繁导致系统内存被消耗完的案例.
在遇到会话建立过于频繁的案例,最有力的说明证据是监听日志,因为awr中的相关数据没有绝对标准(而且awr本身也是一个相对性的东西),而且一般客户对awr中我刚刚列举的数据概念性不强,所以一般只能作为分析的辅助工具,或者为进一步分析监听日志提供理由依据.
发表在 Oracle性能优化
评论关闭

加我微信(17813235971)
加我QQ(107644445)

