aaron8219's Oracle&Linux Technology Blog

今天将一个测试库中的数据导到另一个测试库中，遇到了ORA-31623和ORA-06512错误，以下是大致过程的记录源库为10.2.0.3 64bit，目标库为新装的11.2.0.4 64bit，采用expdp方式开4个并行，并按schema的方式来导出数据Import: Release 11.2.0.4.0 - Production on Mon Aug 31 13:10:00 201

昨天上午接到销售人员电话，说某客户的数据故障，业务都停了，让我去处理一下。急忙从公司赶往客户那边，好在离公司不太远，6站地铁就到了。到了客户那边，赶紧与那边的DBA简单地沟通了一下，了解到他们的库是运行在WINDOW 2008 标准版上的Oracle 11gR1，已经配置了DG，出问题的是主库，早上上班的时候发现业务系统无法连接到数据库，监听也hang死。    我到那边的时候，他们的DB

今天去客户那里搭建DG，当创建RMAN备份集的时候，遇到了个问题，导致备份集始终无法生成，由于客户的备份集为10G左右，一次备份就要一个多小时，开始浪费了不少时间，诊断后发现，原来问题出在MAXPIECESIZE上，下面自己做了个测试，来说明这个故障现象和解决方法：[root@ora10g ~]# su - oracle[oracle@ora10g ~]$ sqlp

今天上午接到某客户电话，说他们的生产库从8:00开始，监控就报CPU资源使用率非常高，最高可达99%，虽然业务还没有挂，但是数据库非常慢，性能出现问题。客户的库是10g单实例，我远程给客户做了AWR报告，下面来具体分析：首先，DB Time非常高，是平时正常情况的好几倍时间，从这一点上就能判断确实存在一定的性能问题

最近在做GC的实验，在GC服务器上软件都顺利安装成功，OMS和自己上面的AGENT也都能够顺利启动，但是就是DB服务器的agent死活配置不成功，一直报错，找了半天也没有发现是什么原因。下面是部分实验过程：GC服务器：[root@ocm2 ~]# su - oracle[oracle@ocm2 ~]$ emctl status omsOr

上周五去某客户那里做数据库巡检，是window 2008系统上10g的一套NC系统的库，已经配置了DG，但是巡检时发现数据库报错：Tue Nov 11 10:13:57 2014LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2

前段时间去客户那里做数据库健康检查，环境是HP-UX，11.2.0.3，原来是10g的库，升级到11g的，发现他们的一个库中报了以下的错误：Errors in file /u01/app/oracle/diag/rdbms/sisdb/sisdb1/trace/sisdb1_j001_7106.trc:ORA-12012: error on auto execute of job

某个客户数据库在巡检的时候发现alert日志里不定期会出现ORA-609错误，大致内容如下：***********************************************************************Fatal NI connect error 12537, connecting to: (LOCAL=NO)  VERSIO

之前在自己的测试环境上做了个异机恢复，原来的库上是配置过EM的，但是在恢复的库上去启动EM就报错了，下面看具体解决过程：PS：原主机名为zlm，恢复出来的主机名为bak[root@bak ~]# su - oracle[oracle@bak ~]$ emctl status dbconsoleTZ set to PRCOC4J Configu

上周去给客户培训，讲到DG部分做实际配置演示的时候，碰到了ORA-28547故障，客户的数据库时11.2.0.1的版本，Window平台。之前已经按照步骤把DG全部配置完成了，当准备在备库启用redo apply的时候，照例先检查一下两边远程归档路径是否有效：select dest_name,status,error from v$archive_dest where dest_id

votedisk无论是对于RAC(10g Clusterware、11g GI)而言，是非常重要的，我们称它为仲裁盘，当RAC集群中的某个节点发生故障而脱网掉线时，就由它来判断是否将其踢出集群，以保证集群正常运行，当votedisk损坏了，也就会导致集群服务无法启动，集群资源都无法加载，最后导致罢工。那么我们平时就要注意对votedisk的备份，在11g中，由于votedisk和ocr默认就会放进

今天早上刚到公司一会，就接到南京客户打来的电话，说他们的核心会员数据库宕机了，让我远程帮忙查看一下。还没来得急看报纸的我赶紧打开电脑，远程连接到客户的服务器进行诊断。客户的生产环境是AIX 6.1上的Oracle 11.2.0.3.0，在凌晨1:40分左右发生的故障。为了不涉及泄露客户隐私，把数据库实例名进行了替换。下面看具体的分析：1. 数据库al

今天在生产库上用exp导出一张临时表，环境是10.2.0.4.0 64bit AIX 6.1，遇到了以下错误：About to export specified table via Conventional Path ....  . exporting table                       TMP_CLSLEVELDATA_WY_5. exporting fo

昨天安装client时采用了InstantClient模式进行安装，今天讲昨天的客户端删掉，重新以administrator模式安装，但是又碰到了几个问题，下面看具体问题分析及处理过程：首先，将原来的ORACLE_HOME和oraInventory目录删除，然后重新安装，并选择administrator模式，前面都很顺利，安装到65%的时候，报错了：

昨天在Redhat6.2(64 bit)上安装oracle 11.2.0.1.0 client(32 bit)，以下是安装中碰到的一些问题及处理过程记录首先解压缩安装包，会生成一个client目录,运行runInstaller时报错，错误如下:[oracle@Ptyjkweb oracle]$ ls -ltotal 627612drwxr-x

上周五去客户处巡检时，发现原来配置的DG备库未与主库同步，特此记录一下在5月14日13：58出现故障，3398日志无法应用，以下是alert日志Thu May 14 13:58:01 2015Errors in file /u01/app/oracle/diag/rdbms/tcdg/sgcrm5/trace/sgcrm5_pr00_3473760.trc:ORA-

用隐含参数强制OPEN数据库后会有很多遗留问题，如：需重建UNDO表空间，此外还会伴随有ORA-08102错误刚才做破坏online日志实验的时候采用加隐含参数强制打开过数据库，之后alert日志就一直会报ORA-08102Wed Jun 24 13:56:24 2015Errors in file /u01/app/oracle/admin/ora10g/bdump/ora1

今天做了一个关于破坏online日志的恢复测试，主要三个场景：测试1：正常关闭数据库后删除非当前日志测试2：正常关库后，删除在线日志文件测试3：非正常关闭数据库，并删除当前在线日志文件我的测试环境是Oracle 10.2.0.1 32bit的数据库，OS版本为red hat 5.3，下面看具体测试经过：测试1：正常关闭数据库后删除非当

今天凌晨某服务器发来nmon的报警，由于设定的阈值是50%，这次达到了51%，以下是nmon中截取的图：可以看到，在03:47分的时候，CPU确实非常高，伴随的是IO也非常高通过AWR分析发现，出现的TOP 10等待事件为“direct path write temp”和“direct path read temp”

oracle用户目录误删除的恢复

今天去客户那里做巡检，碰到一个奇怪的问题，在此做个记录这套库是搭建在windows server 2008上的一套11g RAC，在alert日志中出现了大量下列信息：Wed Apr 29 10:32:48 2015ORA-00020: maximum number of processes (500) exceeded ORA-20 errors will not be

昨天在用DBCA创建数据库的时候，遇到了不少问题，下来来分析一下解决的过程：先是到59%，以及往后，都会报一些错误，如RPCR-1071，PRCR-1066，CRS-2566 等，点“ok”确认会自动跳过，直到完成。但是最后加载数据库资源的时候还是会报错，先是提示ora.asm11g.db资源不存在，用srvctl手动添加数据库资源到CRS时，又报无法添加数据库资源，以及CRS-256

今天早上去一公司合作伙伴那里，协助处理他们某客户的数据库性能问题，那个库是Oracle 10.2.0.1的，前台业务系统是政府某机构查询系统，碰到的问题是首页展示非常慢，与之相关的SQL语句查询结果需要跑59s多，而其他页面相关模块的查询都只需要几秒就可以出结果了。碰到数据库性能问题通常从两个方面着手调整：1. 内存参数调整2. SQL语句优化因此，首先就查看了该库

昨天去一客户那里做巡检，遇到了经典的ora-04030错误，alert日志如下：Tue Oct 28 09:57:46 2014Errors in file /oracle/app/oracle/diag/rdbms/wmsdb/wmsdb/trace/wmsdb_ora_33358038.trc  (incident=177302):ORA-04030: ou

今天开了2台虚拟机做实验，还开了XFT

今天做Windows 2008数据库升级时，安装完

今天误操作不小心点了lock，造成虚拟机次所

10gR2（10.2.0.1）同时启动2个节点主机，经常会出现一些莫名的问题，会莫名其妙的变成OFFLINE和UNKNOWN（之前做完实验关机前，所有资源的状态都是ONLINE的）,如： [root@RAC1 raw]# crs_stat -tName           Type           Target    State    Host        ---------

今天在做RAC-DG实验时，碰到了不少的问题，这个问题是在操作用pifle创建spifle时出现的由于在配置RAC-DG主库参数时，大部分人喜欢直接用alter system set xxx='xxx.xxx' scope=spfile;而我由于不想一条条敲命令，所以先用主库参数创建一个pifle，然后对pfile进行修改，加上我们所需的DG配置参数，然后再把pfile写回spfile参数

今天在配置RAC-DG时，修改主库参数文件后无法用修改后的PFILE启动RAC主数据库，碰到了LRM-00101错误，这是一个语法错误，但是一开始始终没找到解决方法：SQL> create pfile='/rmanbackup/initora11rac.ora' from spfile;File created.SQL> ![oracle@zlm1 ~]$ vi /rman

对RAC环境建立了DATA GUARD后，RAC环境的一个实例关闭后无法启动，报错信息为：ORA-01105和ORA-1677。RAC环境的一个实例关闭后，在重启时报错如下：bash-2.03$ srvctl start inst -d testrac -i testrac2PRKP-1001 : Error starting instance testrac2 on no

在一个节点启动数据库：SQL>startup;ORA-01506: missing or illegal database nameRAC  ora-01506 missing or illegal database name因前面是从PFILE启动，再生成SPFILE的，可能是生成文件出错。[root@rac2 dbs]# string

--==========================================--SPFILE 错误导致数据库无法启动(ORA-01565)--========================================== SPFILE错误导致数据库无法启动    SQL> startup    ORA-01078: failure in process

原文链接：http://blog.youkuaiyun.com/evils798/article/details/8223303[javascript] view plaincopyDBCA删除数据库所有实例后，本想用RMAN duplicate方式克隆DB，因此在$ORACLE_BASE目录下创建了相关的目录admin/dupl/adump ,admin/dupl/d

在安装oracle 11g rac是报错内容如下：INFO: Checking Single Client Access Name (SCAN)...INFO: Checking name resolution setup for "racscan"...INFO: ERROR:INFO: PRVF-4664 : Found inconsistent name resolution

虚拟机：VMware 9.0OS：Window Server 2003 Enterprise (32 Bit)Clusterware：10.2.0.1->10.2.0.4Database：10.2.0.1->10.2.0.5 以前习惯了在Linu环境下搭建玩RAC，昨天第一次尝试在Windows上玩了一把，有人肯定会觉得很不屑，觉得Windows平台没什么实用价值，谁说不是呢

在我们安装RAC的时候，有时候会因为种种报错装上了错误的ASM实例或者LISTENER监听，或者说加入了CLUSTERWARE资源，但是并没有真正起作用，如：如图所示，这里在2个节点分别创建过ASM1和ASM2实例，对应的资源名称分别为ora.RAC1.ASM1.asm和ora.RAC2.ASM2.asm，他们的状态都是UNKONW的，还有每个节点都创建了3个监听，资源名称分别是节

今天做Linux下DG配置的时候，遇到一个现象，tnsname.ora文件配置都正常，tnsping也正常，监听也正常，但是仍然报ORA-12514错误：SQL> set lin 130 pages 130 SQL> select dest_id,error from v$archive_dest;   DEST_ID ERROR---------- -------

还是南京那个客户的库，alert.log日志还报了如下的错误：Fri Oct 17 19:59:51 2014Thread 1 cannot allocate new log, sequence 4722Private strand flush not complete  Current log# 1 seq# 4721 mem# 0: /oradata/sgomp5/

昨天去南京某客户那里调优新上线的业务数据库，在查看alert.log日志时发现在过去的一段时间里，每过几个小时或间隔一段时间，就会报类似以下的内容：Thu Aug 21 09:01:26 2014WARNING: Heavy swapping observed on system in last 5 mins.pct of memory swapped in [8.42