variable 1 varchar2;
exec :1:='HGV2305200017879'
variable 2 varchar2;
exec :2:='5569093'
variable 3 varchar2;
exec :3:='FQC_3D'

select * from BYDMESAMF.MES2_BYD_SFC_KEY t where t.sfc = :1 and t.name = :2 and t.value = :3

select * from BYDMESAMF.MES2_BYD_SFC_KEY t where t.sfc = 'HGV2305200017879' and t.name = '5569093' and t.value = 'FQC_3D?'

DG主备同步状态异常。alert日志报错ORA-01274，MRP进程异常中断。
问题现象
具体现象
问题分析
问题原因
解决方案：
扩展
备库standby_file_management参数为auto
备库standby_file_management参数为manual
备库standby_file_management参数为auto
结论
问题现象
DG主备同步状态异常。alert日志报错ORA-01274，MRP进程异常中断。

- 阅读剩余部分 -

使用MySQL 8.0 克隆(clone)插件快速添加MGR节点
目录
一、MySQL 8.0.17的克隆clone简介
二、MGR现有环境
三、使用clone技术添加MGR节点
3.1 初始化新节点
3.2 新节点安装clone插件和组复制插件
3.3 新节点执行克隆任务
3.4 在原3节点执行修改参数
3.5 新节点启动MGR
四、总结
复制
一、MySQL 8.0.17的克隆clone简介
MySQL 8.0.17的克隆插件允许在本地或从远程 MySQL 实例在线克隆数据，从此搭建从库可以不再需要备份工具（PXB或mysqldump）来实现了。克隆数据是存储在 InnoDB 其中的数据的物理快照，其中包括库、表、表空间和数据字典元数据。克隆的数据包含一个功能齐全的数据目录，允许使用克隆插件进行 MySQL 服务器配置。

克隆插件支持两种克隆方式：

本地克隆：本地克隆操作将启动克隆操作的 MySQL 服务器实例中的数据克隆到同服务器或同节点上的一个目录里。

远程克隆：默认情况下，远程克隆操作会删除接受者(recipient)数据目录中的数据，并将其替换为捐赠者(donor)的克隆数据。（可选）您也可以将数据克隆到接受者的其他目录，以避免删除现有数据。

远程克隆操作和本地克隆操作克隆的数据没有区别，数据是相同的。克隆插件支持复制。除克隆数据外，克隆操作还从捐赠者中提取并传输复制位置信息，并将其应用于接受者，从而可以使用克隆插件来配置组复制或主从复制。使用克隆插件进行配置比复制大量事务要快得多，效率更高。
MySQL 8.0 clone插件提供从一个实例克隆数据的功能，克隆功能提供了更有效的方式来快速创建MySQL实例，搭建主从复制和组复制。本文介绍使用 MySQL 8.0 clone 插件快速添加组复制（MGR）节点的方法。
官网地址：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html

二、MGR现有环境
搭建MGR环境请参考：【DB宝18】在Docker中安装使用MySQL高可用之MGR

现已有MGR集群，多主模式：

3 rows in set (0.00 sec)
复制
docker环境：

[root@docker35 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9dd3d6b221b0 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33067->3306/tcp mysql8020mgr33067
189b5a889665 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33066->3306/tcp mysql8020mgr33066
6ce08dd5dc84 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33065->3306/tcp mysql8020mgr33065
复制
通过clone插件新加节点：172.72.0.18。

三、使用clone技术添加MGR节点
3.1 初始化新节点
mkdir -p /usr/local/mysql/lhrmgr18/conf.d
mkdir -p /usr/local/mysql/lhrmgr18/data

docker run -d --name mysql8020mgr33068 \
-h lhrmgr18 -p 33068:3306 --net=mysql-network --ip 172.72.0.18 \
-v /usr/local/mysql/lhrmgr18/conf.d:/etc/mysql/conf.d -v /usr/local/mysql/lhrmgr18/data:/var/lib/mysql/ \
-e MYSQL_ROOT_PASSWORD=lhr \
-e TZ=Asia/Shanghai \
mysql:8.0.20

cat > /usr/local/mysql/lhrmgr18/conf.d/my.cnf <<"EOF"
[mysqld]
user=mysql
port=3306
character_set_server=utf8mb4
secure_file_priv=''
server-id = 802033068
log-bin =
binlog_format=row
binlog_checksum=NONE
log-slave-updates=1
skip-name-resolve
auto-increment-increment=2
auto-increment-offset=1
gtid-mode=ON
enforce-gtid-consistency=on
default_authentication_plugin=mysql_native_password
max_allowed_packet = 500M
log_slave_updates=on

master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log=lhrmgr18-relay-bin-ip18

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_address= "172.72.0.18:33064"
loose-group_replication_group_seeds= "172.72.0.15:33061,172.72.0.16:33062,172.72.0.17:33063,172.72.0.18:33064"
loose-group_replication_bootstrap_group=OFF
loose-group_replication_ip_whitelist="172.72.0.15,172.72.0.16,172.72.0.17,172.72.0.18"
report_host=172.72.0.18
report_port=3306

EOF

docker restart mysql8020mgr33068

docker ps
mysql -uroot -plhr -h192.168.1.35 -P33065 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33066 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33067 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33068 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33065
mysql -uroot -plhr -h192.168.1.35 -P33066
mysql -uroot -plhr -h192.168.1.35 -P33067
mysql -uroot -plhr -h192.168.1.35 -P33068
docker logs -f --tail 10 mysql8020mgr33065
docker logs -f --tail 10 mysql8020mgr33066
docker logs -f --tail 10 mysql8020mgr33067
docker logs -f --tail 10 mysql8020mgr33068

复制
3.2 新节点安装clone插件和组复制插件
mysql -uroot -plhr -h192.168.1.35 -P33068

-- 安装MGR插件
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

-- 安装clone插件(注意，需要在源MGR3个节点都安装)
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
复制
3.3 新节点执行克隆任务
-- 设置克隆源，将clone_valid_donor_list设置为MGR节点
SET GLOBAL clone_valid_donor_list = '172.72.0.15:3306';

-- 新节点开始克隆
CLONE INSTANCE FROM 'root'@'172.72.0.15':3306 IDENTIFIED BY 'lhr';

-- 由于是docker环境，所以需要重启容器
-- ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
docker restart mysql8020mgr33068

-- 查看克隆进度和状态
MySQL [(none)]> SELECT * FROM performance_schema.clone_status \G
1. row **

         ID: 1
        PID: 0
      STATE: Completed
 BEGIN_TIME: 2020-11-13 15:03:07.076
   END_TIME: 2020-11-13 15:04:31.224
     SOURCE: 172.72.0.15:3306
DESTINATION: LOCAL INSTANCE
   ERROR_NO: 0

ERROR_MESSAGE:

BINLOG_FILE: lhrmgr15-bin.000005

BINLOG_POSITION: 1235
GTID_EXECUTED: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-25
1 row in set (0.01 sec)

MySQL [(none)]> select

->   stage,
->   state,
->   cast(begin_time as DATETIME) as "START TIME",
->   cast(end_time as DATETIME) as "FINISH TIME",
->   lpad(sys.format_time(power(10,12) * (unix_timestamp(end_time) - unix_timestamp(begin_time))), 10, ' ') as DURATION,
->   lpad(concat(format(round(estimate/1024/1024,0), 0), "MB"), 16, ' ') as "Estimate",
->   case when begin_time is NULL then LPAD('%0', 7, ' ')
->   when estimate > 0 then
->   lpad(concat(round(data*100/estimate, 0), "%"), 7, ' ')
->   when end_time is NULL then lpad('0%', 7, ' ')
->   else lpad('100%', 7, ' ')
->   end as "Done(%)"
->   from performance_schema.clone_progress;

7 rows in set (0.01 sec)
复制
3.4 在原3节点执行修改参数
set global group_replication_group_seeds='172.72.0.15:33061,172.72.0.16:33062,172.72.0.17:33063,172.72.0.18:33064';
stop group_replication;
set global group_replication_ip_whitelist="172.72.0.15,172.72.0.16,172.72.0.17,172.72.0.18";
start group_replication;
复制
3.5 新节点启动MGR
-- 由于已有MGR集群是多主模式，需要先设置成多主模式
set global group_replication_single_primary_mode=OFF;
set global group_replication_enforce_update_everywhere_checks=ON;

-- 加入组复制
START GROUP_REPLICATION;

-- 查看组复制成员及状态
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

4 rows in set (0.00 sec)

-- 新节点查询数据库

5 rows in set (0.01 sec
复制
至此，通过clone插件的方式添加MGR节点已成功，非常简单也非常快速。

四、总结
克隆技术的一些限制条件：

版本大于等于8.0.17且不支持跨版本。要求相同版本号，您无法MySQL 5.7和MySQL 8.0之间进行克隆，在8.0.19和8.0.20之间也不可以，而且要求版本>=8.0.17。

克隆操作期间不允许使用 DDL，允许并发DML。

两台机器具有相同的操作系统OS。同一平台同一架构，例如linux to windows、x64 to x32 是不支持。

两台MySQL实例具体相同的 innodb_page_size 和 innodb_data_file_path(ibdata文件名)

同一时刻仅仅允许有一个克隆任务存在

recipient 需要设置变量clone_valid_donor_list

max_allowed_packet 大于2M

doner的undo表空间文件名称不能重复

不会克隆my.cnf文件

不会克隆binlog二进制日志。

仅仅支持innodb引擎。不克隆其他存储引擎数据。MyISAM并且 CSV存储在包括sys模式的任何模式中的表都被克隆为空表。

捐赠者和接受者都需要安装克隆插件

捐赠者和接受者分别需要有至少BACKUP_ADMIN/CLONE_ADMIN权限的账号

不支持通过MySQL router连接到捐赠者实例。

默认情况下，克隆数据后会自动重新启动接受者 MySQL 实例。要自动重新启动，必须在接收方上提供监视进程以检测服务器是否已关闭。否则，在克隆数据后，克隆操作将停止并出现以下错误，并且关闭接受者 MySQL 服务器实例。此错误不表示克隆失败。这意味着必须在克隆数据后手动重新启动接受者的 MySQL 实例。

本文结束。

Windows-使用pscp免密码传输文件到Linux服务器上
工具准备

pscp

http://files.iuie.pub:8080/files/1512702236880.exe

puttygen

http://files.iuie.pub:8080/files/1512703827187.exe

pscp和puttygen的原下载地址

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
带密码方式传文件到Linux服务器
复制 pscp.exe 到 C:\System32目录下
命令行终端打开输入命令
pscp e:\ss.txt root@www.iuie.club:/root
<输入密码>
免密码方式传文件到Linux服务器

1. 生成 key
   首先运行puttygen，打开生成key的界面

点击Generate后，鼠标在进度条下方的空白区域，随机点击或拖动或拖动画圆，生成随机key

完成之后，如图所示，复制公钥，保存私钥到 C:\Users\iuie目录下，文件名为 club.ppk， 登录你的CentOS服务器，进入用户根目录（/root, /home/username）下的.ssh目录，新建并编辑文件 authorized_keys，将刚刚复制好的公钥粘贴进去，注意不需要最后的 rsa-key-20171208，内容以两个等号结尾。

2. 免密方式上传文件到服务器
   pscp -i C:\Users\admin\club.ppk yourfiile root@yourhost:/yourname
   参考：http://blog.csdn.net/ppdouble/article/details/21623547

转载于:https://my.oschina.net/u/3307502/blog/1587025

19c dataguard 快速配置

1，数据库版本

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.11.0.0.0

2，主机信息

192.168.3.230 db01 #主

192.168.3.233 db02 #备

3，主 -开启归档模式

ALTER DATABASE FORCE LOGGING;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

4，tnsnames.ora 主，备都需要配置

cdb01 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.230)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = cdb01)

)

)

sbcdb01 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.233)(PORT = 1521))

(CONNECT_DATA =

  (SERVER = DEDICATED)

  (SERVICE_NAME = sbcdb01)

)

)

5，DBCA to Create a Data Guard Standby

备数据库只需要安装软件既可以，监听不需要配置，dbca自动配置。

在备执行：

dbca -silent

-createDuplicateDB

-gdbName cdb01 #DB_NAME

-sid sbcdb01 #Standby SID

-sysPassword oracle

-primaryDBConnectionString 192.168.3.230:1521/cdb01

-createAsStandby -dbUniqueName sbcdb01 #db_unique_name

日志信息：

[oracle@db02 admin]$ dbca -silent -createDuplicateDB -gdbName cdb01 -sid sbcdb01 -sysPassword oracle -primaryDBConnectionString 192.168.3.230:1521/cdb01 -createAsStandby -dbUniqueName sbcdb01

Prepare for db operation

22% complete

Listener config step

44% complete

Auxiliary instance creation

67% complete

RMAN duplicate

89% complete

Post duplicate database operations

100% complete

Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/sbcdb01/sbcdb011.log" for further details.

6，开启同步

主：

alter system set LOG_ARCHIVE_DEST_2='service=sbcdb01 VALID_FOR=(online_logfiles,primary_role) DB_UNIQUE_NAME=sbcdb01';

alter system set log_archive_config='dg_config=(cdb01,sbcdb01)';

alter system set standby_file_management=auto;

备：

alter system set log_archive_config='dg_config=(cdb01,sbcdb01)';

alter system set standby_file_management=auto;

alter system set fal_server='cdb01';

alter database recover managed standby database using current logfile disconnect;

7，验证同步状态

主：创建pdb01.

SQL> create pluggable database pdb01

admin user admin identified by admin

file_name_convert = ('/pdbseed', '/pdb01');

Pluggable database created.

SQL> SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

     2 PDB$SEED                       READ ONLY  NO

     3 PDB                            MOUNTED

     4 PDB01                          MOUNTED

备：pdb01已经同步完成。

[oracle@db02 admin]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu May 20 23:28:19 2021

Version 19.11.0.0.0

Copyright (c) 1982, 2020, Oracle. All rights reserved.

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.11.0.0.0

SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

     2 PDB$SEED                       READ ONLY  NO

     3 PDB                            READ ONLY  NO

SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

     2 PDB$SEED                       READ ONLY  NO

     3 PDB                            READ ONLY  NO

     4 PDB01                          MOUNTED

2021-05-20T23:28:46.531506+08:00

PR00 (PID:16461): Media Recovery Log /u01/app/19.3/dbs/arch1_53_1073060659.dbf

Recovery created pluggable database PDB01

Recovery copied files for tablespace SYSTEM

Recovery successfully copied file /data2/CDB01/pdb01/system01.dbf from /data2/CDB01/pdbseed/system01.dbf

PDB01(4):WARNING: File being created with same name as in

PDB01(4):primary. Existing file may be overwritten

PDB01(4):Recovery created file /data2/CDB01/pdb01/system01.dbf

PDB01(4):Successfully added datafile 35 to media recovery

PDB01(4):Datafile #35: '/data2/CDB01/pdb01/system01.dbf'

2021-05-20T23:28:48.972799+08:00

Recovery copied files for tablespace SYSAUX

Recovery successfully copied file /data2/CDB01/pdb01/sysaux01.dbf from /data2/CDB01/pdbseed/sysaux01.dbf

PDB01(4):WARNING: File being created with same name as in

PDB01(4):primary. Existing file may be overwritten

PDB01(4):Recovery created file /data2/CDB01/pdb01/sysaux01.dbf

PDB01(4):Successfully added datafile 36 to media recovery

PDB01(4):Datafile #36: '/data2/CDB01/pdb01/sysaux01.dbf'

Recovery copied files for tablespace UNDOTBS1

Recovery successfully copied file /data2/CDB01/pdb01/undotbs01.dbf from /data2/CDB01/pdbseed/undotbs01.dbf

PDB01(4):WARNING: File being created with same name as in

PDB01(4):primary. Existing file may be overwritten

PDB01(4):Recovery created file /data2/CDB01/pdb01/undotbs01.dbf

PDB01(4):Successfully added datafile 37 to media recovery

PDB01(4):Datafile #37: '/data2/CDB01/pdb01/undotbs01.dbf'

PR00 (PID:16461): Media Recovery Waiting for T-1.S-54 (in transit)