今天下午的时候，准备顺手写一个简单的脚本，但是发现很多事情较真起来真是寸步难行。在写脚本的过程中碰到了太多的问题，很多时候感觉像要实现的功能更通用，就得做更多的检查，更多的校验也就意味着有更多的预先条件，这些条件里面有些是规范和建议，有些是按照已有的配置情况，尽管如此，自己感觉还是缺少了太多的检查。
先来说说今天尝试的简单脚本，就是给主库添加standby logfile,这个需求听起来非常简单，都甚至在我的半自动化脚本中隐去了，但是把这个需求要落到纸面上来，简直了。
首先这个需求会涉及到下面的几个数据字典。
V$LOGFILE里是最全的信息，可能有online logfile或者standby logfile，V$LOG里面是在线日志的信息，V$STANDBY_LOG里面是备库日志的信息。
要添加备库日志，有很多的场景，比如已有了备库日志，那样的话是在已有的基础上添加，如果没有则需要按照建议的树目来添加，而添加的备库日志组成员是1个还是2个，这个不同的系统可能会差别很大，可以在v$logfile里面查看。
而如果日志组参差不齐，同一个数据库有的日志组有1个成员，有的有2个成员，这种情况如果判断，难度又得加大，而这个部分我是直接跳过了，因为这个得按照规范来，而不是脚本来满足这种特殊的场景。所以就如同我在开始所说的那样，很多预备条件是规范和建议，有些需要参考已有的配置情况。
当然在实现的过程中，因为有一些判断条件，所以自己就尝试使用PL/SQL来实现，同时又需要包装在shell里面，感觉难度不是大了一点。在实现的时候最终还是发现理论上不可行，
因为需要添加多个日志组，而且要根据日志组成员的情况来动态生成SQL，这种二次动态的情况转换过来也就是不满足范式， 每一列都是不可分割的原子数据项，所以最后调用的时候有些问题，转而使用了shell的方式，当然过程中也碰到了很多问题。
首先是得到日志文件的下标，当前最大的日志组号和需要添加的日志组数
然后尝试了下面的来调用shell和PL/SQL
这样会抛出错误。
ERROR at line 1:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at line 6
一种改进的思路就是下面的方式，分而治之，使用函数来循环迭代。
这种方式就会生成递增的日志创建语句，当然思路完成了，还得细化。
先来说说今天尝试的简单脚本，就是给主库添加standby logfile,这个需求听起来非常简单，都甚至在我的半自动化脚本中隐去了，但是把这个需求要落到纸面上来，简直了。
首先这个需求会涉及到下面的几个数据字典。
V$LOGFILE里是最全的信息，可能有online logfile或者standby logfile，V$LOG里面是在线日志的信息，V$STANDBY_LOG里面是备库日志的信息。
要添加备库日志，有很多的场景，比如已有了备库日志，那样的话是在已有的基础上添加，如果没有则需要按照建议的树目来添加，而添加的备库日志组成员是1个还是2个，这个不同的系统可能会差别很大，可以在v$logfile里面查看。
而如果日志组参差不齐，同一个数据库有的日志组有1个成员，有的有2个成员，这种情况如果判断，难度又得加大，而这个部分我是直接跳过了，因为这个得按照规范来，而不是脚本来满足这种特殊的场景。所以就如同我在开始所说的那样，很多预备条件是规范和建议，有些需要参考已有的配置情况。
当然在实现的过程中，因为有一些判断条件，所以自己就尝试使用PL/SQL来实现，同时又需要包装在shell里面，感觉难度不是大了一点。在实现的时候最终还是发现理论上不可行，
因为需要添加多个日志组，而且要根据日志组成员的情况来动态生成SQL，这种二次动态的情况转换过来也就是不满足范式， 每一列都是不可分割的原子数据项，所以最后调用的时候有些问题，转而使用了shell的方式，当然过程中也碰到了很多问题。
首先是得到日志文件的下标，当前最大的日志组号和需要添加的日志组数
然后尝试了下面的来调用shell和PL/SQL
这样会抛出错误。
ERROR at line 1:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at line 6
一种改进的思路就是下面的方式，分而治之，使用函数来循环迭代。
这种方式就会生成递增的日志创建语句，当然思路完成了，还得细化。
