数据库-工具-oracle dataguard broker部署示例

最新推荐文章于 2024-10-27 16:59:08 发布

原创

最新推荐文章于 2024-10-27 16:59:08 发布 · 1k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #运维

文章目录

1. broker简介[^broker]
2. 使用broker搭建dg环境
3. 压力测试
- 3.1 新增表空间
- 3.2 并发写入

前面已经手动一个个敲 Oracle参数部署了dg的测试环境，当然生产上的情况要复杂的多，我们尽可能多摸摸底。今天主要划分以下任务：

dg管理工具broker的使用
broker和手工dg的对比
性能压力测试

broker是oracle自带的dg管理工具，可以帮助dba快速部署dg，这里做以了解。

select sum(table_rows) from information_schema.tables where table_schema = 'test_schema' ;

select table_name,sum(table_rows)sr from information_schema.tables where table_schema = 'test_schema'  GROUP BY table_name order by sr desc

-- 想了下，测试不需要这样的铺底数据，而是实时同步的情况，所以不需要，我们写个小demo并发插数据就好了

-- 20200521 又想了一下
-- 数据量还是会影响性能的，排除其他因素不考虑（如存储等），delete，update这种还是会受索引数据量的影响，可能会使备库应用慢一下

方便起见，后面我们重新搭起来测试环境后，直接用Navicat同步一下（O(∩_∩)O哈哈~，Navicat也是逻辑同步嘛）

1. broker简介¹

Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置，集中管理操作的一个平台。Data Guard为我们提供了一套高可用的解决方案，但是在实际的使用方面确实显得有一些过于复杂，特别是在需要配置的standby机器多的时候更是如此，一个个机器去登陆配置显得特别的麻烦；在需要做switchover或者是failover的时候情况也是一样，需要操作一系列的命令才能完成一次switchover/failover的操作（同时也应该认识这种操作一般很少除非比如机房挂了这种比较严重的主库起不来的）。Data Guard broker的推出就是为了简化DG复杂的管理过程的，它最大的作用就是集中化的统一管理，下面列出来一些Data Guard broker优势所在：

	使用broker	不使用broker
一般	将primary数据库与全部standby数据库看成一个整体进行管理	必须对primary数据库和各个standby进行单独的操作。
创建standby	通过使用OEM可以轻松的建立一个新的standby	所有操作必须手工进行：拷贝数据/控制/日志文件，设置初始化参数等等
配置和管理	可以在一个地方对所有的数据库进行统一的配置和管理，这些配置会被自动同步到各个数据库中	必须手工的进行配置，然后对Primary和standby进行单独的管理
控制	- 使用一个简单的命令进行failover和switchover的操作 - 通过配置可以自动的进行failover操作	- 必须使用多个SQLPLUS才能完成对数据库的管理
监控	- 自动持续对数据库配置，数据库状态以及其他参数进行自动管理 - 提供详细的数据库状态报告 - 和OEM Events集成	- 没有统一的视图进行管理，只能通过Fixed View一个个进行查看 – 自定义OEM Events管理

1.1 broker组成

broker的组成主要分成两大部分，分别是：

1.1.1 客户端组件

客户端组件是一个管理员与broker服务器端组件的接口，用户通过客户端来发出命令对服务器端的行为进行控制。客户端组件由OEM和DGMGRL两个组成

OEM²（Oracle Enterprise Manager）：图形化的Oracle管理工具，提供了多个向导功能方便DG的管理工作。
DGMGRL（Data Guard command-line interface）：命令行管理界面，可以通过命令很方便的操作以及监控数据库，命令列表见文档。

1.1.2 服务器端组件

在每个配置了broker的数据库上面都存在一个服务器进程进行broker的管理操作，这个服务器进程就是Data Guard broker monitor（DMON），而这个DMON所用到的所有配置信息都会保留在一个配置文件中。这个DMON进程和配置文件就构成了每个数据库上broker的服务器端组件

Data guard broker monitor process（DMON）：DMON是一个用来管理broker的后台进程，这个进程负责与本地数据库以及远程数据库的DMON进程进行通讯（与远端数据库的DMON进程进行通讯的时候使用的是一个 动态注册 的service name “db_unique_name_DGB.db_domain”）。这个进程负责维护配置文件的正确性以及不同数据库之间配置文件的一致性。在第一次创建一个broker配置文件或者是将一个数据库加入一个现存的broker配置中的时候DMON会先收集现有数据库的DG配置信息并保存到配置文件中。
配置文件：配置文件有DMON进行操作，它保存了broker管理的所有的数据库的状态信息，以及数据库相关属性（即数据库的初始化参数信息）的信息。同一个broker配置管理下的每个数据库上面都有一份相同的配置文件。

1.2 配置管理

Broker通过将DG环境划分成数据库配置和数据库这两种对象来简化DG的管理工作。

数据库配置对象：数据库配置是一个包含多个数据库信息的集合，这些数据库信息包括数据库对象当前的形态、状态、及属性设置。同时这个集合可以同时混合了物理standby和逻辑standby。
数据库对象：数据库对象指的是Primary和standby数据库。一般情况下一个数据库对象只包含一个实例，但是在RAC系统中一个数据库对象会包含多个实例。

broker通过将一个DG中的Primary数据库及所有的standby数据库逻辑的组成一个逻辑组来进行集中管理，因此每个broker配置就是一个数据库的逻辑集合，它包含了组成数据库的日志传输服务、日志应用服务等逻辑的对象。DBA可以broker来控制这个逻辑集合的配置，改变它的配置，同时还能监控这个组的整体健康状态。

DMON进程负责设置和维护broker配置，有了DMON的维护之后在实际管理中我们只需要把一个broker配置当初单个的单元管理就行了，剩下的工作由DMON去做，因此当执行一个影响到多个数据库的命令的时候，DMON实际上会进行下面的操作：

在Primary数据库上处理请求。
协调其他相关数据库上的DMON进程处理相应的请求。
更新本地系统中的配置文件。
与其他数据库上的DMON进程通讯以更新各自的配置文件。

每组配置文件中可以包含多个broker配置，但是每个数据库只会维护一组配置文件，因此在RAC环境中，配置文件是由组成这个RAC的各个instance共享的。DMON进程负责各个数据库之间配置文件的同步工作。

DMON进程通过配置文件中设定的数据库的参数来控制数据库的行为，这些属性通常都和数据库的某个DG相关的初始化参数相关联，在通过OEM或DGMGRL修改这些属性的时候，这些属性记录会先保存在配置文件中，然后DMON进程同时也会对相关数据库的参数进行修改，这就要求我们在配置数据库的时候必须使用SPFILE，保证DMON修改之后的参数能保留下来。

2. 使用broker搭建dg环境

环境：

hostname	ip	db_name	db_unique_name	net service name
db3	172.17.0.4	orcl	primary	orcl
db4	172.17.0.5	orcl	standby	orcl

2.0 启动数据库

# primary
    docker run -d --name db3 -p 15213:1521 -p 223:22 -p 11583:1158 -v /mnt/hgfs/E/Workspace/Database/Oracle/data/db3:/data/oracle_data -e oracle_allow_remote=true registry.cn-hangzhou.aliyuncs.com/jydsun/oracle11g_ssg:1.04

# standby
docker run -d --name db4 -p 15214:1521 -p 224:22 -p 11584:1158 -v /mnt/hgfs/E/Workspace/Database/Oracle/data/db4:/data/oracle_data -e oracle_allow_remote=true registry.cn-hangzhou.aliyuncs.com/jydsun/oracle11g_ssg:1.04

因为镜像的原因，我这里挂载映射了本地路径，来存放数据文件，减少虚拟机空间。后面dg搭建好后，测试数据要新建个表空间存储。

2.1 broker配置

2.1.0 预先设置

后面发现有些东西还是要先设置好的…

2.1.0.1 主库开启日志

-- 开启日志
SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database force logging;
SQL> alter database open;

--查看归档
SQL> archive log list;
SQL> select force_logging from v$database;

-- 设置standby log,日志文件可以设置大点500m
--查看Redo和Standby Redo
SQL> select * from v$logfile;		
SQL> select * from v$log;	

SQL> alter database add standby logfile group 21 '/opt/oracle/app/oradata/orcl/standby21.log' size 50M;
SQL> alter database add standby logfile group 22 '/opt/oracle/app/oradata/orcl/standby22.log' size 50M;
SQL> alter database add standby logfile group 23 '/opt/oracle/app/oradata/orcl/standby23.log' size 50M;
SQL> alter database add standby logfile group 24 '/opt/oracle/app/oradata/orcl/standby24.log' size 50M;

2.1.0.2 生成standby controlfile

简直要哭了呀…

还是要用主库生成的standby controlfile来启动备库才行，好多人都没说明这些，他们是真的在已经部署好的dg上搞的嘛

用rman先同步一次备库…

# 在备库执行，连接目标库和辅助数据库,看上去在那个库都能做这里用的是远程连接？
rman target sys/oracle@primary auxiliary sys/oracle@standby

# 恢复数据文件，standby控制文件，standby日志组
RMAN> duplicate target database for standby from active database nofilenamecheck;

# 注意如果没有用rman，控制文件要手动建的，在主库创建standby controlfile，并复制为备库启动的controlfile
# alter database create standby controlfile as '/data/oracle_data/dataguard/standby.ctl';
# scp /data/oracle_data/dataguard/standby.ctl db2:/data/oracle_data/dataguard/standby.ctl
# cp /data/oracle_data/dataguard/standby.ctl /opt/oracle/app/oradata/orcl/control01.ctl
# cp /data/oracle_data/dataguard/standby.ctl /opt/oracle/app/flash_recovery_areduplicate target database for standby from active database nofilenamecheck;a/orcl/control02.ctl

-- 查下备库状态，已经是physical standby了
SQL> select database_role,protection_mode,protection_level,open_mode from v$database;

2.1.1 主库启用broker³

-- 查看dg_broker_start参数设置
SQL>  show parameter dg_broker_start;

-- 启用dg_broker_start，启用后oracle会自动启动一个dmon进程
SQL> alter system set dg_broker_start = true;

-- 默认broker配置文件位置
SQL> show parameter dg_broker_config_file;

2.1.2 主库配置listener.ora和tnsnames.ora

broker里面的连接的service_name默认是<db_unique_name>_DGMGRL，所以需要增加一个监听给broker用。

不配置也可以用命令指定
DGMGRL>edit database db1 set property StaticConnectIdentifier= '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=beijing-fuli-hadoop-01)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=db1)(INSTANCE_NAME=db1)(SERVER=DEDICATED)))'; 

太坑了，broker不能帮助我们自动调整db_unique_name，还是要自己先设置每个库的db_unique_name，保证区分。
-- 主库db3:
SQL> alter system set db_unique_name='primary' scope=spfile;

-- 备库db4:
SQL> alter system set db_unique_name='standby' scope=spfile;

-- 而且这玩意需要重启库才能生效