Fans Or Not

当因为某种原因(比如网络问题)导致Primary和Standby的Archive Gap多到一个难以追赶的数目时，为了节省时间，可能还不如重建Standby来的方便。此时可以使用RMAN的增量备份快速同步，将这个过程缩减到最小。

1，检查archive log sequence#

--Primary
SELECT MAX(sequence#) FROM v$archived_log;
--Standby
SELECT MAX(sequence#) FROM v$log_history;

如果数目相差巨大，请检查standby相关功能是否正常。

2，若功能正常，为了快速roll forward，先停止standby:

SQL> alter database recover managed standby database cancel;

3，检查SCN:

SQL> SELECT CURRENT_SCN FROM v$database;

CURRENT_SCN
-----------
    4143274

也可以通过使用recover standby database的错误提示来获取下一个SCN。暂时shutdown该库。

4，在Primary上进行差异备份

RMAN> backup incremental from scn 4143275 database format 'D:\stdby_%U.bkp';
SQL> alter database create standby controlfile as 'D:\stdby_test.ctl';

这一步是关键，从中断的SCN进行备份，并创建新的standby controlfile。

5，Copy到Standby机器上，并恢复。可以用catalog backuppiece导入新的备份文件。

RMAN> catalog backuppiece 'D:\TEST_52ML9RRT_1_1.BKP';

using target database control file instead of recovery catalog
cataloged backup piece
backup piece handle=D:\TEST_52ML9RRT_1_1.BKP RECID=126 STAMP=760542472

RMAN> catalog backuppiece 'D:\TEST_53ML9RTK_1_1.BKP';

cataloged backup piece
backup piece handle=D:\TEST_53ML9RTK_1_1.BKP RECID=127 STAMP=760542483

RMAN> recover database noredo;

先mount standby database，再做recover。

6，shutdown standby，然后替换standby controlfile。重新mount standby database，并开启日志应用。

SQL> alter database recover managed standby database disconnect from session;

整个过程，唯一需要留意的就是获取正确的SCN。
相关链接：http://www.dba-village.com/village/dvp_papers.PaperDetails?PaperIdA=5766

(2007年就有了，只是最近涉及，才略有关注。是以记录之)

根据DRCP的技术白皮书介绍，凡是使用OCI, OCCI, JDBC, ODP.NET等方式进行连接的应用都可以充分利用DRCP功能，最为典型的，估计就是Apache+PHP之类单线程应用。

DRCP简单配置：

BEGIN
  -- 通过DBMS_CONNECTION_POOL包配置默认的SYS_DEFAULT_CONNECTION_POOL
  DBMS_CONNECTION_POOL.CONFIGURE_POOL(POOL_NAME              => NULL,
                                      MINSIZE                => 10,
                                      MAXSIZE                => 100,
                                      INCRSIZE               => 2,
                                      SESSION_CACHED_CURSORS => 20,
                                      INACTIVITY_TIMEOUT     => 300,
                                      MAX_THINK_TIME         => 600,
                                      MAX_USE_SESSION        => 500000,
                                      MAX_LIFETIME_SESSION   => 86400);
  -- 启动。也可以略过上述配置直接启动默认连接池
  DBMS_CONNECTION_POOL.START_POOL();
  -- 停止
  DBMS_CONNECTION_POOL.STOP_POOL();
END;

几张有用的视图：
1. DBA_CPOOL_INFO 连接池状态和配置信息
2. V$CPOOL_STATS 连接池统计信息
3. V$CPOOL_CC_STATS 连接池分类统计信息

再对TNSNAMES.ORA进行调整，加上SERVER=POOLED，表示连接到连接池而不是DEDICATED方式：

MYAPP =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = myapp.example.com)
      (SERVER=POOLED)
    )
)

PHP简单配置：
PHP需要启用php_oci8_11g这个extension，在php.ini有针对DRCP的配置项

; Connection: Set this to a user chosen connection class to be used
; for all pooled server requests with Oracle 11g Database Resident
; Connection Pooling (DRCP).  To use DRCP, this value should be set to
; the same string for all web servers running the same application,
; the database pool must be configured, and the connection string must
; specify to use a pooled server.
oci8.connection_class =MYPHP

connection_class用于区分连接分类，可以跨应用使用同一个分类。如果不指定connection_class，则系统会自动分配一个唯一标识，但这样会导致多个应用使用同样认证信息的情况下，会启用多个分类，无法共享session池。

Oracle给出了一个统计数据：假设每个session需要400K内存，每个服务器进程需要4M内存，连接池和shared server大小都是100，在5000个客户端连接的情况下，内存使用数据如下:
Dedicated Server Memory used = 5000 X (400 KB + 4 MB) = 22 GB
Shared Server Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB
DRCP Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB

在没有应用层连接池的环境下，启用DRCP是一个非常有益的尝试。

首先，这里只定位于中小型企业，或者换个角度来说，数据库大小处于TB级，每年增长200G左右，日常使用最高并发人数大概300左右，每日发生的事务不超过200万笔。在这个规模下，我们如何选择合适的数据库管理系统？

所谓的企业内部应用系统，这里是指IT企业（软件公司、网络公司）之外的做实业的企业，在这类企业里绝大多数只考虑商业解决方案，所谓的商业方案，当然排除了PostgreSQL、MySQL之类的系统，事实上，在数据库领域，主要只是考虑这么四类产品：Oracle，SQL Server，DB2以及Sybase，当然零星的一些小系统也会考虑MySQL之类当时的非主流产品，但是这类产品往往不入职业IT经理的法眼。大约2005年及之前，Oracle Database主要是9i版本(10g刚刚推出)，SQL Server主要是2000版本，这个年代的选择非常简单，无它，Oracle的集群和Dataguard在当年是处于非常优势并且显眼的地位的，“大系统”选Oracle，“小系统”选SQL Server，几乎不需要动脑筋。没有哪个公司会专门养几个小众的fans来研究小系统大应用。

但是在SQL Server 2005出来后，这个世界貌似出现了点变化。2005版本开始的HA方案和DR方案开始成熟，从数据库集群到数据库镜像，从日志传输到数据库复制，已经初步夯实了大型应用的基石。虽然2000版本就已经存在了log shipping的简陋HA方案，但是这与其说是HA，不如说是快速事务日志备份和传输方案。只有2005版的镜像技术解决了实时同步的问题，配合精心的failover设计，可以解决大多数可用性难题。也就是说，只有到了2005版本，SQL Server的HA方案才值得单独一提。

随着SQL Server 2008的推出，上述四类HA特性得到了加强，比如数据库镜像方案中的日志压缩传输，再比如自动页修复，这个很类似Oracle的block repair。尤其的，在2008版本中各种功能可以自由搭配组合，可以将数据库镜像搭配Failover集群、Log Shipping、快照和Replication等各类功能组成牢固的可靠的数据库系统。

去年，SQL Server Denali的CTP1版本让人看到了更加强大的企业级HA特性，尤其是组合Windows 2008 R2强大的WSFC(Windows Server Failover Clustering)功能后，可以对整个数据库应用进行强化。这里有一点Oracle DBA们可能不是很理解，SQL Server的Instance和Database，跟Oracle的同类数据有着几乎完全相反的意思，简单来说，SQL Server是单个实例操作多个数据库，而Oracle则是多个实例操作单个数据库。事实上，很多资深的Oracle DBA在跳出专业的小圈子接手多个数据库系统时，往往会有一段时间的不适应。在SQL Server的世界里，往往可以见到一个实例下挂着N个数据库。这里需要提起的时，之前所述的HA方案，都是基于单个Database而言的，面对数目众多的Database时，对整套应用所用的数据库进行failover会有点烦。所以Denali中完善的AlwaysOn Availability Groups解决了这个问题。

到了这个时代，Oracle的RAC、Dataguard、Streams、SecureFiles等等令人津津乐道的强大功能，至少光从功能角度来说，SQL Server Denali都给出了对应的解决方案——除了RMAN。我认为SQL Server目前最大的一个不足，就是其本身没有良好的备份、恢复解决方案，虽然基于单个Database的操作异常简单，但是缺乏一个类似RMAN的体验良好的管理器，在对于N个数据库的恢复时非常没有效率。

之所以花这么多篇幅介绍SQL Server而不是其他，是因为DB2多数存在于大型系统中，Sybase已末路黄花，新行业新应用很少选择了，NoSQL世界依旧水中花，SAP的MaxDB基本上挂了，其他开源DBMS则很少涉足企业级应用。在本文所限定的中小型企业级应用系统中，对于数据库系统的选择基本上集中在SQL Server和Oracle两者。尽管Denali还只是CTP3，还没有正式发布，但其增长势头不容忽视，从可见的功能上说，已经并不明显逊于Oracle 10g。

在当前讲究软件+硬件的整体解决方案世界里，如果你还不需要云Box，如果你不是Oracle Fans，如果稍微理性一点，或许SQL Server已经可以在你的备选目录中稍微往上移一位了。