mos，需要账号

建议19.10，19.11问题较多

可以的，会自动比对跳过成功restore的文件。

startup mirgrate然后分别执行catalog，cataproc，utlrp试试

如果os和交换机有bonding还是采用bond更好

1.看看业务逻辑是否可以减少部分sql2.如果是常量方式改成绑定变量3.使用list方式可以提高性能4.考虑同类型insert和update合并成merge

提供topsql的sqlhc报告

你这描述太含糊，别人没法帮你：1、如何不能同步？你手工如何同步的？2、主备的参数及日志等信息要提供

原则上可以的，dg的compatible参数要设置为11g以下

trc/trm直接删不影响，但是alertlog需要使用>的方式清理，否则由于文件句柄打开的原因导致后续日志丢失。

catalog backuppiece ‘/rmanback/2020092922_2uvblll3_1_1.arch’;restore archivelog from sequence 188972;

检查mmon trace是否消耗大量内存，可能遇到bug了,workaround:alter system set “_ash_size”=67108864 scope=spfile;alter system set events ‘4030 trace name heapdump level 536870917;name errorstack level 3’;

nohup imp htjs/HTJS@fwsk file=/orabak/fwskls10/fwskls_20200619.dmp log=/orabak/fwskls10/imp_fwskls_20200619.log full=y FEEDBACK=100000 BUFFER=1000000 COMMIT=y indexes=n &imp/exp基本是对应的，要善于查帮助

在oracle11.2.0.2源库执行

1、把对应的sequence的定义发出来2、上传awr报告原始文件

1、你这个库硬解析较高，和session_cached_cursors没关系(66.3/s)2、主要blocking_session是220，等待事件为cursor: pin S wait on X从ash参数看：SQL> SELECT decode(trunc(&&P3/4294967296),2 0,trunc(&&P3/65536),3 trunc(&&P3/4294967296)) LOC

多个数据文件默认是均衡的，这个也符合性能优化的目的。如果一定要实现你的想法：1、等数据文件快满时在新增新文件2、手工为对象预分配extent到指定数据文件其实你的想法是反数据库优化理论的。

1、看看alertlog有没有啥报错，遇到过temp空间不足导致统计数据收集不了的；2、使用dbms_stats.DELETE_TABLE_STATS清掉1个分区的统计数据，重新在收集看看

裸磁盘你给格式化成文件系统挂起来了啦，这个怎么做asm disk呢？1、umount所有的磁盘2、dd 前面1M的盘头3、重启在看

是11.2以上版本吗？可以采用指定section size的方式对单个文件执行并行备份。

RAC本来就是每个实例使用1个不同的undo表空间的

应该是auto_drop属性是TRUE了，改成FALSE就好了

使用和目标端库一致的exp/imp做导出导入试试。

这几行信息说明有新路径加入asm，然后获取uid失败。可能的原因很多，系统负载、osbug、多路径软件、存储都有可能。系统reboot有没有crash日志呢，如果有可以分析。如果有os监控也应看看故障前是否有异常。

OMF模式下，那些数字后缀的是随机生成的文件。而指定的datafile是软链接。可以去asmcmd ls -lrt看看。

原理上是不会有问题的，如果有问题就是多路径或存储链路方面的问题。做下高可用测试吧。

遇到一个类似的问题，可以这样尝试下：1、multipath.conf或者udev的rules.conf去掉这个盘的映射关系：udevadm trigger; service multipathd restartmultipathd reload2、确认磁盘正常后再添加

看提示是ASM 磁盘头坏了，可以使用kfed备份0号块，然后使用repair尝试修复下。

我的公开课有完整的介绍：PPT：https://www.modb.pro/doc/3021视频录播课程合集：https://www.modb.pro/course/play/49?lsId=1023

问题已关闭: 问题已经得到解决

1、主备库日志大小要保持一致2、备库至少比主库日志组多一组日志文件大小要设置一个参考值后，跟踪高峰期日志切换频率。经验值是不少于15分钟切换一次日志，50M肯定是太小了的。

CMD ping下localhost是否通，否则取hosts文件做下配置看看。

创建个独立的用户，然后设置个database logon trigger做个trace文件看看

SMON CPU 100%

故障描述：这个库之前开了闪回，然后后面空间满了，开发就直接把归档什么都额都删了然后数据库打不来，强制推SCN、resetlogs之后，每次启动半小时宕机，发现SMON一直CPU100%

故障描述：这个库之前开了闪回，然后后面空间满了，开发就直接把归档什么都额都删了然后数据库打不来，强制推SCN、resetlogs之后，每次启动半小时宕机，发现SMON一直CPU100%

oracle迁移后采集数据AUTO模式直方图缺失

3月30日，接到客户通知，其某个数据库在上周六，通过数据泵方式做了迁移后，今天发现部分业务的运行性能明显变慢。需要立即处理并分析问题的原因。远程接入后，通过对相关SQL问题的分析，我们确认是SQL的执行计划改变导致的性能变差，通过将该SQL绑定到正确执行计划的方法，最终恢复了该SQL的正常表现。

ADG 触发ABMR坏块修复问题

环境：REDHAT 6.5 + ORACLE 11.2.0.4.180417 + ADG背景：主库备份期间造成业务影响于是将数据库备份任务转移到备库后，由于备份失败提示坏块主要是LOB 字段的我怎么触发 abmr主要还是想触发ABMR 修复了； 以防以后再次产生坏块

udev绑定导致磁盘异常

故障描述：绑定oracle asm disk失败Mar 16 22:24:47 czzbdj2 udevd[5506]: worker [25366] unexpectedly returned with status 0x0100Mar 16 22:24:47 czzbdj2 udevd[5506]: worker [25366] failed while handling ‘/devices/

内存不足数据库实例重启

2020年3月3日19:14左右。Exadata集群1#节点所有数据库实例发生重启故障。

CRM3数据库 UNDOTBS1表空间undo长期无法释放，导致表空间满无法扩展

早上收到表空间无法扩展的告警，业务中断，添加undo表空间数据文件后业务恢复正常。经查询历史记录UNDOTBS1表空间使用率一直维持在99%左右，其中2T空间为ACTIVE一直无法释放，通过关联vsessions,vtransaction t, dba_undo_extents u视图查询，无长事物与大事物占用，也没有回滚事物大量占用undo。这个数据库2019年9月份开启过闪回归档，后来由于性能

_optimizer_fast_pred_transitivity TRUE ORA-04030

*** 2020-02-26 14:10:35.984*** SESSION ID:(134.8469) 2020-02-26 14:10:35.984*** CLIENT ID:() 2020-02-26 14:10:35.984*** SERVICE NAME:(ods) 2020-02-26 14:10:35.984*** MODULE NAME:(JDBC Thin Client) 202

0303 06：50再次发次类似故障，分析如下：alertlog：Tue Mar 3 06:49:47 2020Errors in file /u01/app/oracle/admin/d

恒丰银行数据仓库在2020年2月2日 7点左右报实例挂掉，alert日志报ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by ‘inst 1, osid 10748084’，进行原因分析。