数据库的几种模式

SQL Server数据库有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式：

1.Simple 简单恢复模式,

Simple模式的旧称叫”Checkpoint with truncate log“，其实这个名字更形象，在Simple模式下，SQL Server会在每次checkpoint或backup之后自动截断log，也就是丢弃所有的inactive log records，仅保留用于实例启动时自动发生的instance recovery所需的少量log，这样做的好处是log文件非常小，不需要DBA去维护、备份log，但坏处也是显而易见的，就是一旦数据库出现异常，需要恢复时，最多只能恢复到上一次的备份，无法恢复到最近可用状态，因为log丢失了。 Simple模式主要用于非critical的业务，比如开发库和测试库，但是道富这边的SQL Server（即使是生产库）大都采用Simple模式，是因为这边的SQL Server大都用于非critical的业务（critical的数据库大都采用Oracle和DB2)，可以忍受少于1天的数据丢失(我们的job每天都会定时备份全库）。

如果需要压缩数据库日志（Shrink语句），将数据库模式切换到简单恢复模式后压缩率才是最高的，如果你的数据库在完整恢复模式或大容量日志回复模式下采用日志压缩，压缩后的日志大小并不会很理想。

2.Full 完整恢复模式,

和Simple模式相反，Full模式的旧称叫”Checkpoint without truncate log“，也就是SQL Server不主动截断log，只有备份log之后，才可以截断log，否则log文件会一直增大，直到撑爆硬盘，因此需要部署一个job定时备份log。Full的好处是可以做point-in-time恢复，最大限度的保证数据不丢失，一般用于critical的业务环境里。缺点就是DBA需要维护log，增加人员成本（其实也就是多了定时备份log这项工作而已）。

3.Bulk-logged 大容量日志恢复

Bulk-logged模式和full模式类似，唯一的不同是针对以下Bulk操作，会产生尽量少的log： 1) Bulk load operations (bcp and BULK INSERT). 2) SELECT INTO. 3) Create/drop/rebuild index 众所周知，通常bulk操作会产生大量的log，对SQL Server的性能有较大影响，bulk-logged模式的作用就在于降低这种性能影响，并防止log文件过分增长，但是它的问题是无法point-in-time恢复到包含bulk-logged record的这段时间。 Bulk-logged模式的最佳实践方案是在做bulk操作之前切换到bulk-logged，在bulk操作结束之后马上切换回full模式。

最大保护模式：
主库上设置：

1. SQL> alter database mount;
2. Database altered.
3. SQL> alter database set standby database to maximize protection;
4. Database altered.
5. SQL> alter database open;
6. Database altered.
7. SQL> select protection_mode from v$database;
8. PROTECTION_MODE                                                                 
9. --------------------                                                            
10. MAXIMUM PROTECTION                                                              
11. 另一个session：
12. SQL> alter system switch logfile;
13. 系统已更改。
14. SQL> create table t (id number(20));
15. 表已创建。
16. SQL> insert into t values (2);
17. 已创建 1 行。
18. SQL> commit;
19. 提交完成。
20. SQL> select * from t;
21.         ID                                                                      
22. ----------                                                                      
23.          2                                                                      
24. SQL> select * from t;
25.         ID                                                                      
26. ----------                                                                      
27.          2                     

复制代码

                                               
备机上：

1. SQL>  select GROUP#,THREAD#,SEQUENCE#,USED,ARCHIVED,STATUS from v$standby_log;
2.     GROUP#    THREAD#  SEQUENCE#       USED ARC STATUS
3. ---------- ---------- ---------- ---------- --- ----------
4.          4          1          0        512 NO  UNASSIGNED
5.          5          1          7       4608 YES ACTIVE
6.          6          0          0        512 YES UNASSIGNED
7.          7          0          0        512 YES UNASSIGNED

复制代码

无法关闭备机数据库，进备机系统禁用网卡：

1. SQL> shutdown immediate;
2. ORA-01154: database busy. Open, close, mount, and dismount not allowed now
3. SQL>

复制代码

 

然后主机上执行insert和commit操作，发现执行commit的时候被阻塞。

但其它session可以查询：

当将备机上的网卡重新启用后，过一会不再阻塞。

所以我观察的结果是，当设置为maximize protection时，备机数据库无法关闭。当备机无法连接时，主机上的数据库事务提交被阻塞（但其它session的查询操作仍有响应），直到备机重新能够连接(此时日志应该自动同步过去)。

最大高可用配置：
主机上设置最大可用模式：
进备机系统禁用网卡：
然后主机上执行insert和commit操作，发现执行commit的时候被阻塞。
但过一会不再阻塞 ：

此时再查数据库模式：
数据库模式显示是最大可用模式，但此时操作不再阻塞（实际上和最大性能模式是一样的）。
在最大可用模式下备机数据库可以关闭。
主机可以查询完整数据
但备机数据不是最新：
重新进入备机模式，待同步后查询：
此时数据已经同步。
所以在最大可用模式下，当redo到达不了备机时，数据库虽然显示模式还是最大可用模式，但实际上和最大性能模式一致。此时，和最大保护模式不一样的是，主库可以任意地进行写入提交操作，不会阻塞，而当备库可用时，这些操作会同步到备库。

最大性能模式：
主库上配置和执行：

 

1. SQL> conn / as sysdba
2. Connected to an idle instance.
3. SQL> startup mount;
4. ORACLE instance started.
5. Total System Global Area  285212672 bytes
6. Fixed Size                  1218992 bytes
7. Variable Size              79693392 bytes
8. Database Buffers          201326592 bytes
9. Redo Buffers                2973696 bytes
10. Database mounted.
11. SQL> alter database set standby database to maximize performance;
12. Database altered.
13. SQL> select protection_mode from v$database;
14. PROTECTION_MODE
15. --------------------
16. MAXIMUM PERFORMANCE
17. SQL> alter database open;
18. Database altered.
19. SQL> select * from t;
20.         ID
21. ----------
22.        100
23.       1001
24.        200
25. SQL> alter system switch logfile;
26. System altered.

复制代码

备机可以关闭：

1. SQL> shutdown immediate;
2. Database closed.
3. Database dismounted.
4. ORACLE instance shut down.

复制代码

备机进入mount和standby模式：

1. SQL> startup mount;
2. ORACLE instance started.
3. Total System Global Area  285212672 bytes
4. Fixed Size                  1218992 bytes
5. Variable Size              79693392 bytes
6. Database Buffers          201326592 bytes
7. Redo Buffers                2973696 bytes
8. Database mounted.
9. SQL> alter database recover managed standby database disconnect from session;
10. Database altered.
11. SQL> select GROUP#,THREAD#,SEQUENCE#,USED,ARCHIVED,STATUS from v$standby_log;
12.     GROUP#    THREAD#  SEQUENCE#       USED ARC STATUS
13. ---------- ---------- ---------- ---------- --- ----------
14.          4          1          0        512 NO  UNASSIGNED
15.          5          1          0        512 NO  UNASSIGNED
16.          6          0          0        512 YES UNASSIGNED
17.          7          0          0        512 YES UNASSIGNED

复制代码

看数据是否同步：

1. SQL> alter database open read only;
2. alter database open read only
3. *
4. ERROR at line 1:
5. ORA-01154: database busy. Open, close, mount, and dismount not allowed now
6. SQL> alter database recover managed standby database cancel;
7. Database altered.
8. SQL> alter database open read only;
9. Database altered.
10. SQL> select * from t;
11.         ID
12. ----------
13.        100
14.       1001
15.        200

复制代码

可以看到表t的数据删除操作已经得到同步。