ITPub博客

源数据库 目标数据库 现在是将PMYDB从mydb数据库插拔到tesdb目标库操作：这里需要注意，原PDB的临时文件不需要包含在其中。否则会报错alter pluggable database pmydb close;alter pluggable database pmydb open;即可将pmydb状态改为OPEN参考惜分飞一篇数据库恢复文档：https://mp.wei

前期准备尽量开启所有表的ALL COLUMNS级别的附加日志。当然也可以在DATABASE层面开启，但是业务高峰期一直被阻塞。这样可以减少因为附加日志不足导致的数据冲突的几率add trandata test.* allcols全库导出做初始化时，expdp参数通过flashback_scn参数取得一致的点。而后启动复制进程时使用start replicat r_aaa aftercsn ****

某客户的oracle数据库中的sqlnet.ora配置了TCP.VALIDNODE_CHECKING， 导致某些终端连接时，不断提示TNS CLOSED。重启监听服务，提示：   TNS-12547: TNS: lost contact     TNS-12560: TNS: protocol adapter error   

某客户的一个Data Guard环境， 某个接口的数据库用户，登录时提示ORA-28000 account locked首先尝试了alter system flush shared_pool, 无果查询dba_users, 无论主备都显示account_status为OPEN查了一堆文档，最终放出大招，将profiled的failed_login_attempts改成UNLIMITED，然后生产环

某大学的一个数据库环境：环境：Primary: Oracle 12.1.0.2 集群软件， 数据库软件为Oracle 11.2.0.4版本。数据文件位于ACFS文件系统中。          Standby: 虚拟机， 11.2.0.4版本同事在搭建DG环境时， 告警日志中出现了大量错误，ORA-00600: internal error code

数据库异地恢复，最后在做recover时报错如下：Starting recover at 24-NOV-23starting media recoveryOracle Error: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01152: file 1 was not

客户的备份软件备份某个数据库时报错。报错信息如下：RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========

给某医院扩容磁盘组时，按照一般流程在线划LUN，映射给主机，修改多路径配置，udev配置，重启udev相关服务。最后磁盘成功加入磁盘组。这时，客户来了一句，在线扩磁盘组不会影响到数据库吧。我登时心头一紧。在通过crsctl stat res -t检查集群资源时，发现一个VIP状态是failover。应用端在连接数据库时应当遇到了问题。首先通过crsctl relocate resource将资源恢

安装好19c集群与数据库软件之后，创建数据库时，尝试两次都报错，尝试手动启动也报错在数据库实例告警日志中，有如下文本：2022-11-22T14:17:03.051481+08:00No connectivity to other instances in the cluster during startup. Hence, LMON is terminating the instance. Pl

环境介绍项目源端目标端操作系统Windows Server 2008R2 64bitOracle Linux 7.8 64bit数据库版本Oracle 11.2.0.1Oracle 19c存储系统文件系统ASM字节序littlelittle  准备测试数据create tablespace mytbs1 datafile 'C:\oradata\mytbs1.dbf&#

近期，一客户历史数据库屡次遇到ORA-00600: internal error code, arguments: [13011]。附带的，还有ORA-01499SQL> analyze table WRH$_IOSTAT_DETAIL validate structure cascade;analyze table WRH$_IOSTAT_DETAIL validate structure

某政府客户，近期不断有数据库性能问题。某日，应用维护人员请求DBA介入杀会话， 因业务办理很不顺畅。首先看到有严重的阻塞：从gv$session_blockers可以看出，被阻塞的会话有156个。业务基本上已经进行不下去了。通过以下SQL查询阻塞的源头：select distinct b.blocker_instance_id, b.blocker_sid, b.blocker_sess_seri

某客户的数据库告警日志中不断提示：Thu Jul 02 10:26:36 2020Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_j001_106746.trc:Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_j001_106746

某客户的一个历史库遇到错误, 数据库不定期崩溃,从日志中可以看到如下内容:Errors in file /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace/orcl2_smon_6364.trc  (incident=336027):ORA-00600: internal error code, arguments: [13013], [5001],

      某医院客户，核心数据库有两个备库。因想将其中一个备库主机挪作测试使用，所以，想把数据库切换成读写模式。这样，就涉及到了做备库的failover动作。这个failover是在另外一个备库，主库都存活的情况下进行的。      Faiover进行得很顺利。Failover之后，修改了此数据库的DG的几个参数，当天以为事情就这么完了

我们在Oracle RAC上，可以创建针对数据库创建一个service，例如：srvctl add service -d orcl -s test1 -i orcl1,orcl2 ...srvctl modify service -d orcl -s test1 -y AUTOMATICcrsctl modify res ora.orcl.test1.svc -attr "AUTO_ST

一套11.2.0.4的RAC，节点时间采用ntpdate使用cron job的方式进行同步。 节点1因硬件故障宕机之后，集群服务久久不能启动。连上主机，采用crsctl stop has -f，crsctl start has的方式进行重启，同时采用crsctl stat res -t -init的方式查看集群基础服务启动的状态。发现CTSS启动时有报错，最终呈现offline的状态。

        背景：客户有两套较大的数据库(一套为10T（A数据库）, 一套为20T（B数据库）)想迁移存储，版本均为12.2.0.1, 采用了ASM管理磁盘，单实例。操作系统分别为linux 6, linux 7。客户想将B数据库的存储迁移到较差的存储，作为只读用途。腾空B数据库的存储之后，将B数据库占用的性能较好的存储分配给A数据库，再将A数据库的数据

RMAN> run { allocate channel ch00 device type 'SBT_TAPE' PARMS="SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)"; backup datafile 1 format='%U';}2> 3> 4> 5>

客户反馈一个备库的数据库软件的LV最近几天增长得比较快，新产生的trace文件也较多。这个备库位于HPUX平台，版本11.2.0.4, 存在较多的读取业务。到达，客户现场之后，在trace目录下发现很多server process的trace文件较大，一般都有十几兆，大的有四十多兆。显然这个有点不正常。查看了几个trace文件，发现其中的module为TEST.exe，其中的数据库连接来自于这个e