Data Guard Broker系列之四:数据库管理

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

数据库状态管理

数据库状态分类

broker管理的数据库可以存在多种不同的状态,在DG中扮演不同角色的数据的状态类型也不一样,详细状态如下。

Primary数据库
  • ONLINE:默认状态。Primary数据库正常打开,日志传送服务正常传送日志到Standby数据库。
    当 数据库转为ONLINE状态的时候,初始化参数LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n会被自动设置以 启用日志传送服务,同时primary数据库以及所有standby数据库的LOG_ARCHIVE_CONFIG参数也会被设置,如果需要的话会根据 broker配置中的信息重新设置数据库的保护模式,同时将数据库打开为读写模式,最后系统将做一个日志却换。
  • LOG-TRANSPORT-OFF:Primary数据库正常打开,日志传送服务不传送日志到Standby数据库。
    当数据库从别的状态切换到LOG-TRANSPORT-OFF状态的时候,参数LOG_ARCHIVE_DEST_STATE_n会被设置成FALSE,这样到所有standby数据库的日志传送将会停止,但是primary数据库的本地归档操作还是正常的。
  • OFFLINE: 数据库关闭,不再接受broker管理,重新启动数据库之后恢复默认状态。
    当数据库从别的状态切换到OFFLINE状态的时候,broker会关闭数据库,当然此时数据库无法被broker管理了,要重新启用的话只需要重启数据库到MOUNT状态就行了,broker会自动的使数据库ONLINE。
physical Standby数据库
  • ONLINE:默认状态。数据库处于MOUNT状态,日志恢复正常,不能进行只读查询。
    当数据库装换成ONLINE状态,相关参数被设置以启用日志恢复。
  • LOG-APPLY-OFF:数据库MOUNT,日志恢复停止,不能进行制度查询。
    当数据库装换成LOG-APPLY-OFF状态时,如果之前数据库ONLINE,则日志恢复关闭,如果之后是READ-ONLY则关闭数据库到MOUNT状态。
  • READ-ONLY:数据库只读打开,可以查询,日志恢复停止。
    当数据库装换成READ-ONLY状态时,日志恢复被停止,同时将数据库打开为只读。
  • OFFLINE:数据库关闭,不再接受broker管理,重新启动数据库之后恢复默认状态。
    当数据库从别的状态切换到OFFLINE状态的时候,broker会关闭数据库,当然此时数据库无法被broker管理了,要重新启用的话只需要重启数据库到MOUNT状态就行了,broker会自动的使数据库ONLINE。
logical Standby数据库
  • ONLINE:默认状态。数据库只读打开,日志恢复正常。
    转换为ONLINE状态时,broker将打开数据库,同时启用database guard以防止对表数据的修改,同时修改SQL应用相关参数启用SQL应用。
  • LOG-APPLY-OFF:数据库只读打开,日志恢复关。
    转换为LOG-APPLY-OFF状态时,broker将停止SQL应用草操作。
  • OFFLINE:数据库关闭,不再接受broker管理,重新启动数据库之后恢复默认状态。
    当数据库从别的状态切换到OFFLINE状态的时候,broker会关闭数据库,当然此时数据库无法被broker管理了,要重新启用的话只需要重启数据库到MOUNT状态就行了,broker会自动的使数据库ONLINE。
数据库各种转换路径
数据库各种转换路径

 

相关DGMGRL命令

1. 查看一个数据库当前的状态

直接使用show database命令,然后查看“Intended State”一项

DGMGRL show  database  torcla
Database
  
Name :             torcla
  
Role :             PHYSICAL  STANDBY
  
Enabled :          YES
  
Intended  State :   ONLINE
  
Instance ( s ) :
    
torcla
 
Current  status  for  " torcla " :
SUCCESS

2. 修改数据库的状态

通过edit命令来修改数据库的状态,命令语法如下

EDIT  DATABASE  ' db_unique_name SET  STATE = ' database_state ' ;

下面我们来个设置数据库offline的操作

-- 设置我们的standby数据库OFFLINE
DGMGRL edit  database  torcla  set  state = ' OFFLINE ' ;
Operation  requires  shutdown  of  instance  " torcla on  database  " torcla "
Shutting  down  instance  " torcla " ...
ORA - 01109 database  not  open
 
Database  dismounted .
ORACLE  instance  shut down .
-- 此时再看数据库的state已经是OFFLINE了
SYS @ torcla startup  mount
ORACLE  instance  started .
 
Total  System  Global  Area  1191182336  bytes
Fixed Size                    1259312 bytes
Variable Size               355207376 bytes
Database Buffers            819200000 bytes
Redo Buffers                 15515648 bytes
Database  mounted .
DGMGRL show  database  torcla
Database
  
Name :             torcla
  
Role :             PHYSICAL STANDBY
  
Enabled :          NO
  
Intended State :   OFFLINE
  
Instance ( s ) :
    
torcla
 
Current  status  for  " torcla " :
SHUTDOWN
 
-- 下面我们启动下这个数据库,然后再看数据库的state,又变成了ONLINE
SYS @ torcla startup  mount
ORACLE  instance  started .
 
Total  System  Global  Area  1191182336  bytes
Fixed Size                    1259312 bytes
Variable Size               355207376 bytes
Database Buffers            819200000 bytes
Redo Buffers                 15515648 bytes
Database mounted .
 
DGMGRL show  database  torcla
Database
  
Name :             torcla
  
Role :             PHYSICAL STANDBY
  
Enabled :          YES
  
Intended State :   ONLINE
  
Instance ( s ) :
    
torcla
 
Current status for " torcla " :
SUCCESS

数据库属性管理

数据库属性分类

broker管理的数据库属性包含两类:第一类是可监控的属性,第二类是可配置的属性。

可监控属性
顾名思义,可监控的属性是能在broker的界面中看到属性的设定值,但是不能够修改。
可配置属性
可配置属性既能监控,同时还能够动态的修改。可配置属性在数据库处于任何状态的是很都能够修改,不过当数据库处于OFFLINE状态或者是DISABLE状态的时候,属性的修改会先记录到broker配置文件中,在数据库broker被启用之后会被应用到据库中。

对于可配置的数据库属性,broker会保证启用了broker的数据库它在broker配置文件后中记录的数据库的属性和数据库运行所使用的参数是一致的,但这也有两种情况:

  • 如果对应的数据库参数是可以动态更新的,那么broker配置文件、SGA、spfile这三个地方所涉及的属性值将会是一样的。
  • 如果对应的数据库参数不能动态更新,那么在数据库重启之前broker配置文件、SGA这两个地方的参数值是一样的,spfile中参数值要在数据库重新启动之后才能与broker配置文件值一致。

显示/修改数据库属性

1. 同show database verbose命令可以查看数据库当前的属性设置,值显示为“(monitor)”的自然就是可监控的属性了,其他的属性都属于可配置的。

DGMGRL >   show  database  verbose  torcla
 
Database
  
Name :             torcla
  
Role :             PHYSICAL STANDBY
  
Enabled :          YES
  
Intended State :   ONLINE
  
Instance ( s ) :
    
torcla
 
  
Properties :
    
InitialConnectIdentifier         =  ' torcla.mycompany '
    
LogXptMode                       =  ' SYNC '
    
Dependency                       =  ''
    
DelayMins                        =  ' 0 '
    
Binding                          =  ' OPTIONAL '
    
MaxFailure                       =  ' 0 '
    
MaxConnections                   =  ' 1 '
    
ReopenSecs                       =  ' 300 '
    
NetTimeout                       =  ' 180 '
    
LogShipping                      =  ' ON '
    
PreferredApplyInstance           =  ''
    
ApplyInstanceTimeout             =  ' 0 '
    
ApplyParallel                    =  ' AUTO '
    
StandbyFileManagement            =  ' MANUAL '
    
ArchiveLagTarget                 =  ' 3600 '
    
LogArchiveMaxProcesses           =  ' 2 '
    
LogArchiveMinSucceedDest         =  ' 1 '
    
DbFileNameConvert                =  ' torclb, torcla '
    
LogFileNameConvert               =  ' torclb, torcla '
    
FastStartFailoverTarget          =  ''
    
StatusReport                     =  ' (monitor) '
    
InconsistentProperties           =  ' (monitor) '
    
InconsistentLogXptProps          =  ' (monitor) '
    
SendQEntries                     =  ' (monitor) '
    
LogXptStatus                     =  ' (monitor) '
    
RecvQEntries                     =  ' (monitor) '
    
HostName                         =  ' orainst.desktop.mycompany.com '
    
SidName                          =  ' torcla '
    
LocalListenerAddress             =  ' (ADDRESS=(PROTOCOL=tcp)(HOST=orainst.desktop.mycompany.com)(PORT=8000)) '
    
StandbyArchiveLocation           =  ' /data1/dg/databases/torcla/redolog '
    
AlternateLocation                =  ''
    
LogArchiveTrace                  =  ' 0 '
    
LogArchiveFormat                 =  ' log-%s-%t-%r.arc '
    
LatestLog                        =  ' (monitor) '
    
TopWaitEvents                    =  ' (monitor) '
 
Current  status  for " torcla " :
SUCCESS

2. 通过edit database命令修改数据库属性,基本语法如下

EDIT  DATABASE  db_unique_name  SET  PROPERTY  ' property_name = property_value ;

下面实战一下,修改下数据库的NetTimeout属性

-- 先看下当前的值
DGMGRL show  database  torcla  NetTimeout
  
NetTimeout  =  ' 60 '
 
-- 将60修改成120
DGMGRL edit  database  torcla  set  property  ' NetTimeout ' = 120 ;
Property  " NetTimeout updated
-- 再看torclb的broker日志文件,可以看到broker在修改log_archive_dest_2值
DG 2009 - 08 - 31 - 07 : 21 : 25          0 2 Executing  SQL  [ alter system set log_archive_dest_2  =   ' service="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=orainst.desktop.mycompany.com)(PORT=8000)))(CONNECT_DATA=(SERVICE_NAME=torcla_XPT.mycompany)(INSTANCE_NAME=torcla)(SERVER=dedicated)))" ' '    LGWR SYNC AFFIRM delay=0 OPTIONAL max_failure=0 max_connections=1   reopen=300 db_unique_name="torcla" register net_timeout=120  valid_for=(online_logfile,primary_role) ' ]
 
-- 这个时候torcla的broker日志文件也有动作,是在同步broker配置……
DG 2009 - 08 - 31 - 07 : 21 : 32          0 2 0 DRCX Start receiving metadata file : / data1 / dg / 10.2.0.2 / A10db / dbs / dr2torcla . dat
DG 2009 - 08 - 31 - 07 : 21 : 32          0 2 0 DRCX Receiving block #1, 86 blocks.

日志传送管理

使用broker配置日志传送管理需要涉及下面这些可配置的数据库属性。

LogShipping
决定是否传送日志到指定的数据库,和primary数据库的状态LOG-TRANSPORT-OFF不同的是LOG-TRANSPORT-OFF会停止向所有的standby数据库传送日志。
  • ON:传送日志到指定数据库
  • OFF:不传送日志到指定数据库
LogXptMode
这个属性设置的是LOG_ARCHIVE_DEST_n中传送模式那部分
  • SYNC:相当于LGWR, SYNC, AFFIRM
  • ASYNC:相当于LGWR, ASYNC, NOAFFIRM
  • ARCH:相当于ARCH
StandbyArchiveLocation
指定standby数据库上从primary接收的归档日志的存放位置,和standby自己本地的日志归档不一样,standby数据库本地的日志归档由LOG_ARCHIVE_DEST_n指定。当然这个值最好设置和本地归档位置一样最好。
AlternateLocation
这个属性是和StandbyArchiveLocation配合使用,如果设置了这儿属性,一旦StandbyArchiveLocation指定的目录因为磁盘满之类的原因fail了的话数据库就会归档日志存放在这个属性指定的位置上。
Dependency
这个参数设置一个standby数据库的归档日志依赖于别的那个standby或者是primary数据库,这个参数在多个数据库放在一个机器上的是很很有用,可以保证不用再同一个机器上存好几份同样的归档日志。

除了上面几个重要的设置之外还有Binding、MaxFailure、NetTimeout、ReopenSecs这几个属性,这些属性会在数据库加入broker的时候自动导入,通常不需要修改。

日志应用管理

日志应用相关的可配置参数有下面这些。

同时适应于Redo Apply和SQL Apply的
  • ApplyInstanceTimeout
  • DelayMins
  • PreferredApplyInstance
只适用于Redo Apply的属性
  • ApplyParallel
只适用于SQL Apply的属性
  • LsbyASkipTxnCfgPr
  • LsbyDSkipTxnCfgPr
  • LsbyASkipCfgPr
  • LsbyDSkipCfgPr
  • LsbyASkipErrorCfgPr
  • LsbyDSkipErrorCfgPr
  • LsbyMaxEventsRecorded
  • LsbyTxnConsistency
  • LsbyRecordSkipErrors
  • LsbyRecordSkipDdl
  • LsbyRecordAppliedDdl
  • LsbyMaxSga
  • LsbyMaxServers

数据库保护模式

设置数据库的保护模式

保护模式与其他设置之间的关系

 

保护模式 日志传送模式 是否需要standby日志? 是否能和fast-start failover一起用
MAXPROTECTION SYNC
MAXAVAILABILITY SYNC
MAXPERFORMANCE ASYNC或ARCH ASYNC时是

PS:在MAXAVAILABILITY和MAXPROTECTION保护模式下,standby database的standby redo logfile组个数必须大于等于standby database的standby redo logfile组数,并且standby redo logfile的大小必须大于等于redo logfile. 同时,standby redo logfile组的编号(v$standby_log.group#)必须于primary database上的standby redo logfile组编号(v$log.group#)一致。

使用broker来设置保护模式也是通过edit configuration来操作

-- 先看下当前的设置,是MaxPerformance
DGMGRL show  configuration
 
Configuration
  
Name :                 FSF
  
Enabled :              YES
  
Protection Mode :      MaxPerformance
  
Fast - Start  Failover DISABLED
  
Databases :
    
torcla  -  Physical  standby  database
    
torclb  -  Primary  database
-- 然后我们将它变更为MaxAvailability
DGMGRL edit  configuration  set  protection  mode  as  maxavailability ;
Operation  requires  shutdown  of  instance  " torclb on  database  " torclb "
Shutting  down  instance  " torclb " ...
Database  closed .
Database  dismounted .
ORACLE  instance  shut down .
Operation  requires  startup  of  instance  " torclb on  database  " torclb "
Starting  instance  " torclb " ...
ORACLE  instance  started .
Database  mounted .
DGMGRL show  configuration
 
Configuration
  
Name :                 FSF
  
Enabled :              YES
  
Protection Mode :      MaxAvailability
  
Fast - Start Failover DISABLED
  
Databases :
    
torcla  -  Physical  standby  database
    
torclb  -  Primary  database
 
Current status for " FSF " :
SUCCESS

broker还是很聪明的,会自动的关闭primary数据库然后将保护模式修改为MaxAvailability。

不同的保护模式对broker操作的影响

1. 当升级保护模式的时候,broker会自动的重启primary数据库。降低保护模式级别的时候是不需要重启数据库的。
2. switchover操作不会改变当前的保护模式。
3. 做手工的failover之后,如果原来保护模式是MaxProtection的话会被自动降级为MaxPerformance;如果是其他模式的话则保持不变。
4. fast-start failover所作的自动的failover操作不会改变数据库的保护模式。
5. 做disable操作或remove database之前,broker会检查disable之后是否还能保证满足当前的保护模式,如果不能的话disable/remove会失败。
6. fast-start failover启用的是很不能做disable configuration操作。

 

数据库监控状态查看

broker会自动的收集同一个配置之下的所有数据库的健康状态,管理员只需要通过简单的show命令就可以查看数据库的状态了。命令格式如下

show  database  db_unique_name  statue_name

可用的状态命令列表如下:

StatusReport
显示所有broker检查到的问题
LogXptStatus
显示日志传送的状态
InconsistentProperties
显示不一致的数据库属性
InconsistentLogXptProps
显示不一致的日志传送设定

命令操作示例

DGMGRL show  database  torclb  statusreport
STATUS  REPORT
       
INSTANCE_NAME     SEVERITY ERROR_TEXT
               
torclb        ERROR ORA - 16737 the redo transport service for standby database " torcla " has an error

DGMGRL show  database  orclt1cn_a LogXptStatus
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME                 STATUS
             
torcla              torclb
 
DGMGRL show  database  torcla  InconsistentProperties
INCONSISTENT PROPERTIES
   
INSTANCE_NAME          PROPERTY_NAME           MEMORY_VALUE           SPFILE_VALUE           BROKER_VALUE
 
DGMGRL show  database  torcla  InconsistentLogXptProps
INCONSISTENT LOG TRANSPORT PROPERTIES
   
INSTANCE_NAME           STANDBY_NAME          PROPERTY_NAME           MEMORY_VALUE           BROKER_VALUE

参考至:http://www.dbabeta.com/2009/learn-data-guard-broker_db-management.html

如有错误,欢迎指正

邮箱:czmcj@163.com

作者:czmmiao  文章出处:http://czmmiao.iteye.com/blog/2124880
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
22天前
|
存储 人工智能 Cloud Native
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
在9月20日2024云栖大会上,阿里云智能集团副总裁,数据库产品事业部负责人,ACM、CCF、IEEE会士(Fellow)李飞飞发表《从数据到智能:Data+AI驱动的云原生数据库》主题演讲。他表示,数据是生成式AI的核心资产,大模型时代的数据管理系统需具备多模处理和实时分析能力。阿里云瑶池将数据+AI全面融合,构建一站式多模数据管理平台,以数据驱动决策与创新,为用户提供像“搭积木”一样易用、好用、高可用的使用体验。
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
|
1月前
|
存储 人工智能 Cloud Native
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
阿里云瑶池在2024云栖大会上重磅发布由Data+AI驱动的多模数据管理平台DMS:OneMeta+OneOps,通过统一、开放、多模的元数据服务实现跨环境、跨引擎、跨实例的统一治理,可支持高达40+种数据源,实现自建、他云数据源的无缝对接,助力业务决策效率提升10倍。
|
2月前
|
存储 人工智能 Cloud Native
云栖重磅|从数据到智能:Data+AI驱动的云原生数据库
阿里云数据库重磅升级!元数据服务OneMeta + OneOps统一管理多模态数据
|
1月前
|
Java API 数据库
Data jpa 增删改查的方法分别有哪些
Data jpa 增删改查的方法分别有哪些
|
4月前
|
SQL Oracle 关系型数据库
关系型数据库Oracle Data Guard
【7月更文挑战第11天】
43 1
|
4月前
|
SQL 监控 Oracle
关系型数据库Oracle 的Data Guard:
【7月更文挑战第7天】
59 3
|
4月前
|
Oracle 关系型数据库 数据库
|
6月前
|
存储 SQL Oracle
关系型数据库文件方式存储DATA FILE(数据文件)
【5月更文挑战第11天】关系型数据库文件方式存储DATA FILE(数据文件)
131 3
|
5月前
|
SQL Java 数据库
Java一分钟之-Spring Data JPA:简化数据库访问
【6月更文挑战第10天】Spring Data JPA是Spring Data项目的一部分,简化了Java数据库访问。它基于JPA,提供Repository接口,使开发者能通过方法命名约定自动执行SQL,减少代码量。快速上手包括添加相关依赖,配置数据库连接,并定义实体与Repository接口。常见问题涉及主键生成策略、查询方法命名和事务管理。示例展示了分页查询的使用。掌握Spring Data JPA能提升开发效率和代码质量。
96 0
|
14天前
|
SQL 关系型数据库 MySQL
12 PHP配置数据库MySQL
路老师分享了PHP操作MySQL数据库的方法,包括安装并连接MySQL服务器、选择数据库、执行SQL语句(如插入、更新、删除和查询),以及将结果集返回到数组。通过具体示例代码,详细介绍了每一步的操作流程,帮助读者快速入门PHP与MySQL的交互。
29 1
下一篇
无影云桌面