ORA-01089 select fail over database link on RAC ADG Standby
前段时间配的一套11203 RAC ADG on EXADATA Machine的环境,在ADG 的standby side的node2 通过dblink查询时提示ora-1089错误,但是在node1 查询正常,DG的recover 进程是在node1 上..
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
前段时间配的一套11203 RAC ADG on EXADATA Machine的环境,在ADG 的standby side的node2 通过dblink查询时提示ora-1089错误,但是在node1 查询正常,DG的recover 进程是在node1 上..
最近有套库突然目录使用告警,发现TRACE 目录使用较高,发现在bdump 目录中每分钟都生成一个cdmp*目录,且每个目录中含大量的文件,这是一套oracle 11.2.0.3 rac on hpux 11.31的数据库,
该环境是主备两套11.2.0.3 2-NODES RAC ON EXADATA Machine ,存储在ASM, 数据库70TB 大小, 闲时每天1T归档日志, 忙时每天可达4T+归档, 之前朋友重建DG一直使用主机上一个shell 放后台,我查看了该shell 确实不算复杂,但是duplicate 一直hang在开始
10.2.0.4 2nodes Oracle RAC ON HPUX 平台的环境, 计划升级到10.2.0.5, 前期升级clusterware 软件非常顺序,可是在跑root102.sh时还没跑完主机突然reboot, 尝试启crs 报错:The clusterware daemons are running from . But you are patching /oracle/product/10.2.0/crs10g
在做一个普通的分区表(HEAP TABLE)收集统计信息时进程报错意外终止,后台日志未出现ora-600等内部错误,这是一套11.2.0.3.7 oracle RAC 2-nodes on HPUX-ia 11.31的运行环境,这里简单的记录一下排查过程。
SQL> exec DBMS_STATS.GATHER_TABLE_STATS (ownname => ‘ANBOB’ , tabname => ‘TAB_ERROR’ , cascade => true, estimate_percent => dbms_stats.auto_sample_size,method_opt=>’FOR TABLE FOR ALL COLUMNS SIZE REPEAT’, degree => 8,no_invalidate=>false);
*
ERROR at line 1:
ORA-20011: Approximate NDV failed: ORA-12801: error signaled in parallel query server P001, instance qdim1:im1 (1)
ORA-01722: invalid number
ORA-07445: exception encountered: core dump [LpxFSMSaxSE()+449] [SIGSEGV] [ADDR:0xFD26CFB5] [PC:0x400000001117F881] [Address not mapped to object] []
—– Current SQL Statement for this session (sql_id=6qt1f1pg1dkzs) —–
SELECT UPPER(XMLType(CHR(60) || CHR(58) || CHR(113) || CHR(120) ||
在OEL5.8 安装12C R2 beta1时 遇到ins-30131错误, 以前在OEL5装过12c R1,这个错误第一次见,错误日志有两个关键字
”[INS-13001] Environment does not meet minimum requirements.
[INS-30131] Initial setup required for the execution of installer validations failed.
看到一篇笔记 Oracle 12cR1, Shutdown abort of a PDB seems to perform commit 提到在12r1 存在一个奇怪的现象,shutdown abort 在当前会话会执行隐式提交, 这有点颠覆我们之前版本中的理论, 我们都知道shutdown abort 应该是rollback 当前未提交的事务
前面的方法我们还原了问题现象,因为CBO使用错误的统计信息,使用了INDEX_JOIN的方式, 现在尝试如何快速的解决该问题,也就是禁用INDEX_JOIN或使用我们指定的执行计划。
SQL涉及表的所有字段都有索引,不过分布在两个索引上,ORACLE 优化器会选择了使用index join的执行计划,避免了对table的访问路径, 因当时cpu过高,查询慢没成功记录两个索引的分区信息..
前几日发现有套数据库的连接数有些异常,查看当时的session时发现还存在大量的”killed”状态的会话存在v$session 视图中,确认几个小时前有从数据库做过alter system kill session
有时从dba_tab_cols看到的表名是奇怪的sys_开头,有时在desc table时不显示,这里记录一下 Function index \VIRTUAL column \ unused column对列的影响,除了unsed column会把列搞的很“不一般” ,还有一些特殊场景。
2015已跑远,在春节放假前一天,交上迟到2015年个人考卷,长话短说简单总结一下:
anbob@life>select things from time where year=2015;
整理的一个清理Oracle数据库监听日志的脚本,可以部署到监听进程的owner用户的crontab中(RAC通常是grid, 单实例通常是oracle), 实现的是监听日志大于1GB时,归档监听日志文本格式的文件如listener.log ,自动压缩保存, 后期循环自动覆盖, 11G 引入的ADR, XML格式的文件19c前也无法自动清理,这个shell 目前是自动rm 7前天的, 关于19c 的日志自动清理后期会分享
对于临时表不应该收集统计信息,TEMP TABLE是会话级数据,因为每个进程可以填充的数据不一样, 手动收集的统计信息如果不在insert的会话为0 ,影响了CBO生成正确执行计划
元旦期间帮一朋友恢复了套数据库, 情景是这样的,25号0时有做RMAN 0级备份含datafile和当时的archivelog,25号白天删除了一个非常重要的表空间, 现在需要恢复那个表空间,是一套单实例的11.1.0.6 的WINDOWS平台的数据库, 接手时只有上面的6个备份集文件(只有DATAFILE AND ARCHIVELOG)和软件,和当前的control file
前天有套库发现表空间分了很大但是使用的非常少,想收回多余浪费的空间放回ASM,删了两个表空间应该可以释放1T左右的空间,但是ASM DISKGROUP的free space时,并没有增长, 也就是删除的空间没有释放, 开始以为遇到了BUG, 其实原因很简单, 只是在这简单记录这个问题的提个醒。
A web application using Tuxedo always keep 50 long connection to local database which then issues a SELECT from local db to remote db over shared db link(it’s created last weekend). But to run for a period of time after the found the remote db sessions become full(ora-18)
前段时间数据库出现了几次ORA 600 [ktspfmdb:objdchk_kcbnew_3]错误,引起该错误的是一条insert sql.
I faced a very interesting question today, An oracle database 11.2.0.3 RAC database ON hpux one had to many scheduler jobs , And the job’s owner is sys, All jobs name all like ‘KWQICPOSTMSGDEL_’, All these jobs has no start date as well no interval.