今天有如下收获：

1.connect by的一个案例

开发的同事来找我问一条sql，说是表就两百多行，半天跑不出来。是类似这样一条sql：

select regexp_substr(name, '[^,]+', 1, rownum) name
          from t_string where id=2
        connect by rownum <=
                   length(regexp_replace(name, '[^,]', null)) + 1;
这是我做实验还原的sql，实验用的表：


     就我这四行数据的表在虚拟机上把内存跑干了，报没有memory给connect by继续折腾了。
      具体原因我还没有特别确定。后面研究明白了补充，总之，这条sql不能这么写，因为执行计划会先走connect by，然后过滤where条件，可是如果不加where条件也能跑出来，加上就不行了，还不知道为啥，反正注意下。
根据这个有如下俩点收获：
第一：学会了一种把字符串转成行的写法。
第二：这个sql的正确写法应当是：
 with a as (select name from t_string where id=3)
 select regexp_substr(name, '[^,]+', 1, rownum) name
          from a
        connect by rownum <=
                   length(regexp_replace(name, '[^,]', null)) + 1;
          而且，with as的“临时表”返回的结果集必须只有一条，否则，出来的结果集就是按第一条结果集得到的字符串拆分，后面的用null补充。我想这应该是跟start with默认第一行开始有关系吧？不确定。

2.dg检查的一些常用sql

总结了一些dg日志检查的sql，都是抄来的，包括从官文等等：

下面这些是在主库上执行的：
一、
找到每个线程最新的日志序列号

the most recently archived sequence number for each thread：

SELECT MAX(SEQUENCE#), THREAD#

FROM V$ARCHIVED_LOG

WHERE RESETLOGS_CHANGE# =

(SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG)

GROUP BY THREAD#;
然后备库上执行：

select sequence#,name,applied from v$archived_log;

能比对出差了多少日志没应用

二、
这个完成了上面干的事儿，但这里今天由于报错，还有个sql的收获

the most recently archived redo log file at each redo transport destination:

SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#

FROM V$ARCHIVE_DEST_STATUS

WHERE STATUS <> 'DEFERRED'

AND STATUS <> 'INACTIVE';

select DEST_NAME,STATUS,ERROR,to_char(FAIL_DATE,'yyyymmdd hh24:mi:ss') from v$archive_dest order by 4 desc;
这个能查出来destination的报错信息，截图没截到。后面再遇到再补充。

三、

 find out if any log files are missing at the redo transport destination:

SELECT LOCAL.THREAD#, LOCAL.SEQUENCE#

FROM (SELECT THREAD#, SEQUENCE#

FROM V$ARCHIVED_LOG

WHERE DEST_ID = 1) LOCAL

WHERE LOCAL.SEQUENCE# NOT IN

(SELECT SEQUENCE#

FROM V$ARCHIVED_LOG

WHERE DEST_ID = 2

AND THREAD# = LOCAL.THREAD#);

DEST_ID 可在V$ARCHIVE_DEST中获得

select dest_id,destination from v$archive_dest;

手工处理物理备库的redo gap

1.备库上执行：

SELECT * FROM V$ARCHIVE_GAP;

2.在主库上执行：

SELECT NAME FROM V$ARCHIVED_LOG

WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;

查出主库上这些归档的位置

3.拷贝这些文件到物理备库，然后执行：

ALTER DATABASE REGISTER LOGFILE

4.重复1-3，直到第一步中查不出来gap为止。

注意：

1.V$ARCHIVE_GAP查不出来最后丢失的日志序列号，比如目前日志已经到100了，但是从77以后日志就开始不能被接收应用了，那这78到100的gap该视图不会显示。

2.The V$ARCHIVE_GAP view on a physical standby database only returns the gap that is currently blocking Redo Apply from continuing.

所以要不停重复1-3，知道查不出结果为止。

其实这个配了fal_server也就不用这么麻烦了。

今天突然有事，先写到这儿。