11g data guard(PHYSICAL STANDBY)配置

一、 Preparing the Primary Database for Standby Database Creation
1、安装redhat 5.5系统和11g r2数据库,相关参数如下

Database DB_UNIQUE_NAME TNS Ip
Primary first first 192.168.1.2
Physical standby sencode sencode 192.168.1.3

2、Enable Forced Logging
2.1)查看数据库是否开启force log
select force_logging from v$database;
2.2)如果得到结果是YES,跳过2.3)
2.3)ALTER DATABASE FORCE LOGGING;

3、Enable Archiving
3.1)查看数据库是否启动归档模式
archive log list;
3.2)如果得到类此下面结果跳过步骤3.3)
Database log mode Archive Mode
Automatic archival Enabled
3.3)开启归档模式
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

4、创建Primary Database和Standby Database的tns,确保两者能够相互tnsping通
Note:tns配置成dedicated server模式

二、Step-by-Step Instructions for Creating a Physical Standby Database
1、Create a Backup Copy of the Primary Database Datafiles
方法一、冷备份
关闭Primary Database数据库(immediate)拷贝datafile、redo、undo、temp到Standby Database位置
Note:如果确保自己有能力在没有redo、undo、temp文件的情况下恢复数据库,可以只拷贝datafile(建议全拷)
方法二、rman备份
Rman 备份,然后在Standby端恢复

2、Create a Control File for the Standby Database
ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/tmp/control01.ctl’;
Scp /tmp/control01.ctl oracle@192.168.1.3:/u01/oradata/first/

3、Create a Parameter File for the Standby Database
3.1)Create a parameter file
CREATE PFILE=’/tmp/pfile’ FROM SPFILE;

3.2)Modify the Parameter File
3.2.1)Primary Database
first.__db_cache_size=71303168
first.__java_pool_size=4194304
first.__large_pool_size=4194304
first.__oracle_base=’/u01’#ORACLE_BASE set from environment
first.__pga_aggregate_target=121634816
first.__sga_target=192937984
first.__shared_io_pool_size=0
first.__shared_pool_size=100663296
first.__streams_pool_size=4194304
*.audit_file_dest=’/u01/admin/first/adump’
*.audit_trail=’db’
*.compatible=’11.2.0.0.0′
*.control_files=’/u01/oradata/first/control01.ctl’,
‘/u01/flash_recovery_area/first/control02.ctl’
*.db_block_size=8192
*.db_domain=’dg’
*.db_name=’first’
*.db_unique_name=’first’

*.db_recovery_file_dest=’/u01/flash_recovery_area’
*.db_recovery_file_dest_size=4039114752
*.diagnostic_dest=’/u01′
*.dispatchers='(PROTOCOL=TCP) (SERVICE=firstXDB)’
*.log_archive_config=’dg_config=(first,second)’
*.log_archive_dest_1=’LOCATION=/u01/archive valid_for=(all_logfiles,all_roles)
*.log_archive_dest_2=’service=second lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=second’
*.log_archive_format=’%t_%s_%r.arc’
*.log_archive_dest_state_1=enable
*.log_archive_dest_state_2=enable
fal_server=second

*.memory_target=314572800
*.nls_language=’SIMPLIFIED CHINESE’
*.nls_territory=’CHINA’
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile=’EXCLUSIVE’
*.undo_tablespace=’UNDOTBS1′
standby_file_management=auto

3.2.2)Standby Database
second.__db_cache_size=71303168
second.__java_pool_size=4194304
second.__large_pool_size=4194304
second.__oracle_base=’/u01’#ORACLE_BASE set from environment
second.__pga_aggregate_target=121634816
second.__sga_target=192937984
second.__shared_io_pool_size=0
second.__shared_pool_size=100663296
second.__streams_pool_size=4194304
*.audit_file_dest=’/u01/admin/second/adump’
*.audit_trail=’db’
*.compatible=’11.2.0.0.0′
*.control_files=’/u01/oradata/first/control01.ctl’
*.db_block_size=8192
*.db_domain=’dg’
*.db_name=’first’
*.db_unique_name=’second’

*.db_recovery_file_dest=’/u01/flash_recovery_area’
*.db_recovery_file_dest_size=4039114752
*.diagnostic_dest=’/u01′
*.dispatchers='(PROTOCOL=TCP) (SERVICE=firstXDB)’
*.log_archive_config=’dg_config=(first,second)’
*.log_archive_dest_1=’LOCATION=/u01/archive valid_for=(all_logfiles,all_roles) db_unique_name=second’
*.log_archive_dest_2=’service=first lgwr async valid_for=(online_logfiles,primary_role)
*.log_archive_format=’%t_%s_%r.arc’
*.log_archive_dest_state_1=enable
*.log_archive_dest_state_2=enable
fal_server=first

*.memory_target=314572800
*.nls_language=’SIMPLIFIED CHINESE’
*.nls_territory=’CHINA’
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile=’EXCLUSIVE’
*.undo_tablespace=’UNDOTBS1′
standby_file_management=auto

scp /tmp/pfile oracle@192.168.1.3:/tmp/
拷贝主库密码文件到备库,确保sys密码一致
scp /u01/oracle/dbs/orapwfirst oracle@192.168.1.3:/u01/oracle/dbs/orapwsecond

4、Start the Physical Standby Database
4.1)Startup pfile=’/tmp/pfile’ mount(可以直接open,oracle会自动置于read only模式)
4.2)Add STANDBY LOGFILE
ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/oradata/first/slog1.rdo’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/oradata/first/slog1.rdo’) SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/oradata/first/slog1.rdo’) SIZE 50M;
4.3)Start Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

5、Start Primary Database
Startup pfile=’/tmp/pfile’;

6、Verify the Physical Standby Database Is Performing Properly
6.1)standby database,
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
6.2)Primary Database
ALTER SYSTEM SWITCH LOGFILE;
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
6.3)standby database
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
观察SEQUENCE#在Primary Database和standby database是否一致

7、Create Spfile
create spfile from pfile=’/tmp/pfile’;(Primary Database和standby database)

LOG_ARCHIVE_DEST_n参数属性

AFFIRM和NOAFFIRM
AFFIRM保证在日志写入进程(LGWR)能够继续写入可以重用主数据库上的联机重做日志文件之前,能够同步执行并成功完成到备用目的地的归档重做日志文件或备用重做日志文件的所有磁盘I/O操作,因此,LGWR在写入到主数据库上的本地联机重做日志文件之前一直等待。需要AFFIRM来达到没有数据丢失的目的
NOAFFIRM指示将要同步地执行到归档重做日志文件和备用重做日志文件的所有磁盘I/O操作;在备用目的地上的磁盘I/O操作完成之前,可以重用主数据库上的联机重做日志文件

ALTERNATE和NOALTERNATE
当原始的归档目的地失效时,ALTERNATE指定一个可替换使用的LOG_ARCHIVE_DEST_n目的地

ARCH和LGWR
ARCH默认情况下指定ARCH进程负责将重做数据传送到归档目的地。LGWR指定LGWR进程执行日志传输操作

DB_UNIQUE_NAME和NODB_UNIQUE _NAME
DB_UNIQUE_NAME为目的地指定唯一的数据库名字

DELAY和NODELAY
DELAY指定在备用站点上归档重做数据日志和将归档重做日志文件应用到备用数据库之间的时间间隔;DELAY可以用来保护备用数据库免受损坏或错误的主数据的影响。如果没有指定DELAY和NODELAY,默认采用NODELAY

DEPENDENCY和NODEPENDENCY
DEPENDENCY允许向一个目的地传输重做数据,然后在多个被备用数据库之间共享它的归档的重做日志文件。当创建DEPENDENCY时,必须使用REGISTER和SERVICE属性

LOCATION和SERVICE
每个目的地必须指定LOCATION或SERVICE属性来标识一个本地磁盘目录(通过LOCATION)或一个远程数据库目的地(通过SERVICE),Log Transport Service可以向此数据库传送重做数据

MANDATORY和OPTIONAL
如果目的地是OPTIONAL,到此目的地的归档操作可能失败,然而仍可以重用联机重做日志文件并最终可以重写它。
如果一个MANDATORY目的地的归档操作失败,则不能重写联机重做日志文件

MAX_FAILURE和NOMAX_FAILURE
MAX_FAILURE指定在主数据库永久放弃备用数据库之前执行的重新打开尝试的最大次数

NET_TIMEOUT和NONET_TIMEOUT
NET_TIMEOUT指定在终结网络连接之前主系统上的日志写入器(log writer)进程等待来自网络服务器进程的状态所允许的秒数。默认值是180秒

QUOTA_SIZE和NOQUOTA_SIZE
QUOTA_SIZE指示本地目的地能够使用的一个磁盘设备上的512字节物理存储块的最大数量

QUOTA_USED和NOQUOTA_USED
QUOTA_USED标识在一个特定的目的地上归档的512字节数据块的数量

REGISTER和NOREGISTER
REGISTER指示归档重做日志文件的位置将记录在对应的目的地

REOPEN和NOREOPEN
REOPEN指定在归档器(archiver)进程(ARCn)或日志写入器进程(LGWR)尝试再次访问一个以前失效的目的地之前允许的最小秒数(默认值是300秒)

SYNC和ASYNC
在使用日志写入器进程(LGWR)时,SYNC和ASYNC指定网络I/O操作是同步执行还是异步执行。默认情况下,SYNC=PARALLEL,用于存在多个使用SYNC属性的目的地的情况下。所有的目的地应该使用相同的值

TEMPLATE和NOTEMPLATE
TEMPLATE为备用目的地上的归档重做日志文件或备用重做日志文件的名字定义了一个目录规范和格式模版。可以在主或备用初始化参数文件中指定这些属性,但是该属性只适用于正在归档的数据库角色

VALID_FOR
VALID_FOR根据以下的因素来标识Log Transport Service什么时候可以向目的地传送重做数据:(1)数据库当前运行在主角色还是备用角色下,(2)当前是否正在该目的地的数据库上归档联机重做日志文件、备用重做日志文件或者这两类文件。该属性的默认值是VALID_FOR= (ALL_LOGFILES, ALL_ROLES)。其他的取值包括PRIMARY_ROLE、STANDBY_ROLE、ONLINE_LOGFILES和STANDBY_LOGFILE

VERIFY和NOVERIFY
VERIFY指示archiver进程应该检验完成的归档重做日志文件内容的正确性。默认值是NOVERIFY

mysql中group by操作

在我的思想中,group by函数应该的使用应该是SELECT 列表中指定的每一列也必须出现在 GROUP BY 子句中,除非这列是用于聚合函数,但是今天帮同事调试一个mysql中的group by函数,让我大跌眼镜,当时感觉不可思议,然后回来做了个简化版试验,试验过程如下:

mysql表结构
mysql> desc t;
+——-+————–+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+——-+————–+——+—–+———+——-+
| id | int(11) | YES | | 0 | |
| name | varchar(100) | YES | | NULL | |
| aa | varchar(45) | YES | | NULL | |
+——-+————–+——+—–+———+——-+
3 rows in set (0.01 sec)

插入数据
mysql> select * from t;
+——+——+——-+
| id | name | aa |
+——+——+——-+
| 1 | aaaa | bbbb |
| 1 | 1111 | 2222 |
| 1 | 2222 | 33333 |
| 1 | 2222 | 44444 |
| 2 | 2222 | 44444 |
| 2 | 2222 | 1111 |
| 3 | 2222 | 1111 |
| 1 | 2222 | 44444 |
| 1 | 2222 | 44444 |
| 1 | 2222 | 44444 |
| 3 | 2222 | aaaa |
+——+——+——-+
11 rows in set (0.00 sec)

group by 查询语句
mysql> select id,count(1) ,aa from t group by id;
+——+———-+——-+
| id | count(1) | aa |
+——+———-+——-+
| 1 | 7 | bbbb |
| 2 | 2 | 44444 |
| 3 | 2 | 1111 |
+——+———-+——-+
3 rows in set (0.00 sec)

在本试验中,一共select id,count(1),aa,结果group by按照规则,除了聚合函数(count(1))外,其他两列(id,aa)都应该包含在group by中,可是试验只是包含了id。

对试验结果的说明
1、包含在group by后面的id列的count(1)统计数据为正确的
2、按照正常思维,aa的数据不能展示出来,可是mysql选择了展示表中aa数据的第一条
3、上述2也是个人猜测,暂时未查到官方相关说明