今天，我通过网络，收看了博森瑞老师邱玉利的公开课，主要讲解了他平时工作中遇到的问题和解决方法，我感觉不错，受益匪浅。
备份必须归档模式做物理备份。
数据库万不得已打不开了，考虑用隐含参数打开后，抓紧把数据库导出，然后重建库，再导入。此时，不能用rman备份了，因为数据库用隐含参数打开的数据库已经不一致了，用rman备份没用。
active 表明该redo对应的db buffer cache的脏块还没写盘呢。
inactive损坏好解决，但是active和current不好解决。
今天我在网上查看了oracle redolog的三种状态的解释说明：
Current：目前正在写的日志组；当前的日志文件，该日志文件是活动的，当前正在被使用的，在进行崩溃恢复时，current日志文件是必须的
Active：目前不在写，但是还未进行ckpt，即cache中脏数据还未写入datafile，恢复时需要用到此日志组。活动的非当前日志，该日志可能已经完成归档，也可能没有归档，活动的日志文件在crash恢复时会被用到
Inactive：目前不在写，已进行ckpt，实例恢复不需要此日志组。非活动日志，该日志在实例恢复时不再需要，但是在介质恢复时可能会用到。inactive状态的日志也可能没有被归档。如果数据库在归档模式，在未完成归档之前，日志文件也不允许被覆盖，这时候活动进程会处于Log File Switch（Archiving Needed）等待之中。
unused：日志从未被写入，这类日志可能是刚被添加到数据库或者在Reset Logs之后被重置。被使用之后，该状态会被改变。
总结：由于每3秒进行的检查点并不是完全检查点，并不保证脏数据完全写入datafile，所以做实验可以看到，手工执行alter system switch logfile后，原来current的日志处于active状态，说明对应的脏数据没有写完成，要经过N多个三秒后，状态会变成inactive。
上述说明对内通信网卡在ocr丢失，那就单独用上面的oifcfg setif命令设置下。
操作系统都有debug命令。
主机是个老主机，主板上的电池时间没电了，最后改下时间就好了。
看问题思路：数据库错误—>操作系统错误--->再看时间是否有问题。
用户查看说数据文件是recover状态。
上述在dictionary check beiging后报错说是数据字典的问题。
v$视图查看的是控制文件，其它字典是静态的。
上面这个问题的原因是有人把数据库基表改了。
小提示：我们应该定期做备份恢复实验。
正常数据库不要做安全加固，风险很大。
crs起不来，一定会在tmp下有名为“crsctl.进程号”的日志文件，该文件说明起不来的原因
如果客户端和数据库在一个网段不会出现意外断开。
如果是不同网段，之间还有防火墙，那肯定就是防火墙问题
rac监听的是别名，不是ip地址。rac经常遇到上述tns-12545的问题。
解决方法：
把数据库的别名的解析，拷贝到客户端的host文件中。
上图中用两个用户查询的时间是不一样的。
上面的原因就是hp有两个时区文件，当时系统管理员用vi只改了一个文件，另外一个没改。所以改hp的时区时一定要用命令去改，别用vi去改。
pmon进程是回收资源回收没释放的进程，pmon是负责整个数据库的进程。
杀操作系统进程比杀数据库后台进程释放资源快。
数据文件最大的尺度是4万兆个数据块数。假设数据块是8k，那么数据文件最大就是32G。达大最大32G，数据文件头块就会破坏。
数据文件头块是给操作系统用的。
所以，一定要把数据文件自动扩展关了。
设置事件10231就是跳过坏块导出，再导入。
附件列表
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/28916011/viewspace-1618978/ ，如需转载，请注明出处，否则将追究法律责任。
