当因为某种原因(比如网络问题)导致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 [...]
Archives for August 2011
《失控》
《失控》成书于1994年，凯文·凯利在20年前就预料到今天的社会，在很多方面，可能今天的读者比20年前的人更能受到启发。 是的，启发。 回过头来看这本书，其实它仿佛并不是一本书，至少不是一本常规意义上的书，它是预言书，是严肃的哲学思考，是抒情散文，是数学定理。让我感到，用任何语言评论它都是多余的，于是仅随手摘录几点浓缩了的观点以做管窥： 在需要终极适应性的地方，就越需要失控的群件。放弃控制权，增加不确定，反而获得一种更稳定的平衡。 群体规律，往往来自于具备自适应能力的简单法则。复杂，来源于简单，越是复杂的系统，越是需要底层的简单。 要想洞悉一个系统所蕴藏的涌现结构，最快捷、最直接的也是唯一可靠的方法就是运行它。 与其费尽将任一功能最优化，不如使多数功能“足够好”，这才是大型系统的生存之道。 建立一个巨大的系统确实需要许多阶段，而这些阶段对于系统本身的运转并非必须。拇指让人类发展出了智能，但今天的人类可以离开拇指而思考。 …… 我认为《失控》所唯一传授的，便是大型系统建立、运行和生存之道。
PHP和DRCP小记
(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 [...]
中小型企业的数据库系统选择
首先，这里只定位于中小型企业，或者换个角度来说，数据库大小处于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已经可以在你的备选目录中稍微往上移一位了。
SQL Server Denali的FileTable简介
老一辈的DBA们在处理非结构化数据时可能会条件反射的有这么一种思路：将二进制文档、图片等存放于文件系统上，在数据库中记录其元数据，这种经典方案一直持续到Oracle 11g的推出，在SecureFiles的理念得以普及后，一些企业级应用的非结构化数据存储方案有了更多的选择。今天，SQL Server Denali也引入了这个功能，命名为FileTable。 FileTable基于SQL Server 2008引入的FileStream功能进行构建，在概念和功能上都和SecureFiles几乎一致，充分利用了DBMS的优势来管理非结构化数据，同时也打通了文件系统的壁垒，直接通过Windows资源管理器来访问FileTable文件夹。这种特性使非结构化数据的全文索引、SQL操纵文件、基于DBMS的安全机制和快速访问机制等得以轻松的实现。 在SQL Server中启用FileTable的方式非常简单，只需要启用数据库级的非事务型访问(和FILESTREAM的配置是相对独立的)，然后就可以通过SQL Server Management Studio或者简单的TSQL来创建FileTable了： CREATE TABLE DocumentStore AS FileTable WITH ( FileTable_Directory = ’DocumentTable’, FileTable_Collate_Filename = database_default ); GO 在denali(至少到CTP3为止)中，相比其他功能而言，FileTable目前还不支持以下功能： 不支持分区 不支持分发(Replication) Windows中无法进行回滚或恢复等操作(TSQL可以) 自服务数据库(Contained Databases)的支持尚不完善 在备份恢复方面，因为启用非事务型访问，所以无法实现常规意义的基于事务日志的PIT(Point-in-Time)恢复。 对于Windows文件操作，无法进行审计(Audit) 继Oracle和SQL Server之后，估计还会有更多的DBMS会陆续增加类似特性。
