TT02 (PID:97272): Error 16063 archiving LNO:4 to 'tns_dgjycdb'

同事巡检发现主库alert日志时不时有些报错（adg正常)
错误信息如下：

TT02 (PID:97272): Error 16063 archiving LNO:4 to 'tns_dgjycdb'

分析了alert日志，日志从某天开始有报错，而那天确实做了新增备机传输归档日志的动作。
意思是源端的日志传输有了两个目标端：

根据官方资料提示：
Error 16063 archiving LNO:n to ‘’ (Doc ID 2722180.1)

Solve the root cause and make sure all ASYNC destinations perform in similar way fixes the error ORA-16036 

注意此次修改并不是根据参考的资料去修改隐含参数_REDO_TRANSPORT_ASYNC_MODE，这个本身要求重启数据库生效，在线的生产环境是不可行的。关键是先确保两个目标端都采用相同的ASYNC异步方式，如果还没解决，才能再考虑其它处理办法。
观察log_archive_dest_2的配置没有设置ASYNC参数，于是将该参数做相应调整

alter system set LOG_ARCHIVE_DEST_2='service=tns_dgjycdb async VALID_FOR=(online_logfiles,primary_role) DB_UNIQUE_NAME=dgjycdb' scope=both sid='*';

参考说明：
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/LOG_ARCHIVE_DEST_n-parameter-attributes.html#GUID-E3626025-2E4C-4C61-B5DF-2BB106F0A349

The LOG_ARCHIVE_DEST_11 through LOG_ARCHIVE_DEST_31 parameters do not support the SYNC attribute.

The redo data generated by a transaction must have been received by every enabled destination that has the SYNC attribute before that transaction can commit.

On primary databases and logical standbys, destinations 1 through 10 default to ASYNC (real-time cascading).

On physical standbys, snapshot standbys, and far sync instances, destinations 1 through 10 default to ARCH transport mode. (Note that the ARCH attribute is deprecated; the use of ARCH in this situation simply indicates non-real-time cascading.)

Destinations 11 through 31 always default to ASYNC.

完成后，观察alert不再报错。