Oracle10gR2 Logical Standby(四)转换逻辑备库的过程

关于Oracle10gR2逻辑备库，之前写过几篇：
Oracle10gR2 Logical Standby(一)概念与原理
 Oracle10gR2 Logical Standby(二)配置前需要考虑的问题
 Oracle10gR2 Logical Standby(三)配置逻辑备库

这里记录一下Oracle10gR2物理备库转换为逻辑备库的过程中，Oracle都做了哪些操作。从alert中可以获得很多有用的信息：当执行alter database recover to logical standby xxxx的命令后，首先启动基于SCN的不完全恢复(Oracle10g会自动开启并行恢复，这个例子中启动了15个并行恢复进程)。然后clear online redo logfile，但是Oracle10g在将备库置于manged standby状态的时候就提前将这个clear的动作做了，所以这里记录的是previously cleared，然后将备库激活，调用nid修改数据库的DBID。

alter database recover to logical standby shtest
Thu Jun 5 14:02:55 2008
Media Recovery Start: Managed Standby Recovery (shtest)
Thu Jun 5 14:02:55 2008
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 15 processes
Media Recovery Log /oradata/archive/shtest/1_2274_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2275_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2276_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2277_655399684.arc
Thu Jun 5 14:02:56 2008
Incomplete Recovery applied until change 20447678
Thu Jun 5 14:02:56 2008
Media Recovery Complete (shtest)
RESETLOGS after incomplete recovery UNTIL CHANGE 20447678
Resetting resetlogs activation ID 54725959 (0×3430d47)
Online log /oradata/shtest/redo01_01.dbf: Thread 1 Group 1 was previously cleared
Online log /oradata/shtest/redo01_02.dbf: Thread 1 Group 1 was previously cleared
Online log /oradata/shtest/redo02_01.dbf: Thread 1 Group 2 was previously cleared
Online log /oradata/shtest/redo02_02.dbf: Thread 1 Group 2 was previously cleared
Online log /oradata/shtest/redo03_01.dbf: Thread 1 Group 3 was previously cleared
Online log /oradata/shtest/redo03_02.dbf: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 20447676
Thu Jun 5 14:03:01 2008
Setting recovery target incarnation to 2
Thu Jun 5 14:03:01 2008
Converting standby mount to primary mount.
Thu Jun 5 14:03:01 2008
ACTIVATE STANDBY: Complete - Database mounted as primary (shtest)
*** DBNEWID utility started ***
DBID will be changed from 54167428 to new DBID of 55371925 for database SHTEST
DBNAME will be changed from SHTEST to new DBNAME of SHTEST
Starting datafile conversion
Setting recovery target incarnation to 1
Datafile conversion complete
Database name changed to SHTEST.
Modify parameter file and generate a new password file before restarting.
Database ID for database SHTEST changed to 55371925.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
Thu Jun 5 14:03:03 2008
ARC1: Archival disabled due to instance shutdown
Shutting down archive processes
Archiving is disabled
Thu Jun 5 14:03:03 2008
Completed: alter database recover to logical standby shtest

Posted by NinGoo at 2008-06-05 14:45 | 『数据库』 | No Comments »

Oracle10.2.0.4 Linux64版本监听存在多个子进程

Update:还是被这个监听搞了一回，即使加了SUBSCRIBE_FOR_NODE_DOWN_EVENT_ =OFF。连续两天出现swap和load过高导致数据库无法提供服务，甚至OS都无法登陆。在ps后发现有两个监听进程，kill后系统恢复正常。按照Oracle的建议，删除了ONS的配置文件$ORACLE_HOME/opmn/conf/ons.config，暂时看起来正常了

连续两台全新安装的Linux64+Oracle10.2.0.4的环境，启动listener后，都出现了4个进程：

more /etc/issue
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
Kernel \r on an \m

ps -ef | grep tns
oracle 3244 1 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3245 3244 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3246 3245 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 3247 3245 0 09:37 ? 00:00:00 /u01/oracle/product/10.2/bin/tnslsnr listener_stb -inherit
oracle 5841 5504 0 10:12 pts/2 00:00:00 grep tns

之前一台Linux32位平台从9i升级上来的没有这个问题，一套Linux64平台从10.2.0.3升级上来的RAC也没有这个问题。在10.2.0.3之前，曾经有一个bug 4518443，listener可能产生一个或者多个子进程，最终导致监听hang住无法提供服务。这回到好，一启动直接就开4个进程。Oracle在10.2.0.3版中加入了4518443的patch，应该是屏蔽了某段代码，而看来到10.2.0.4他们认为这段问题代码找到了解决方法，又加了进来，结果在Linux64平台上问题更严重了，faint。

通过Bug 4518443提供的workaround可以暂时屏蔽该问题，在listener.ora中加入：

SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF

按照metalink的说法，这个语句关闭了监听自动向ONS(Oracle Notification Services)注册，正是这个注册可能导致监听启动子进程。ONS是RAC中的一个组件，禁用该特性将导致RAC的FAN(Fast Application Notification)特性不可用。还好我这里两台都是单机，这么解决应该没什么问题。

Bug啊，总是来了又走，走了又来，就像移动联通电信，分了又合，合了又分，呵呵。

Posted by NinGoo at 2008-05-30 10:33 | 『数据库』 | 2 Comments »

不使用SimpleDB的10个理由

自从Amason推出SimpleDB，基于key-value键值对的分布式数据存储系统受到了广泛关注，类似的系统还有Apache的CouchDB，以及最近重磅推出的Google App Engine的基于BigTable的Datastore API等，毫无疑问，分布式数据存储系统提供了更好的横向扩展能力，是未来的发展方向。但是现阶段，对比传统的RDBMS，也还有一定的差距和不足。Ryan Park撰文指出了SimpleDB的10大不足之处：

1.数据完整性无法保证

类似SimpleDB的分布式数据存储系统目前还无法实现和RDBMS一样严格的完整性约束，例如唯一性约束和外键约束等，所以数据的完整性需要在应用中来实现。

2.数据一致性无法保证，将导致非常糟糕的用户体验

SimpleDB做写入操作做了优化，调用API时只需要写入数据到一台SimpleDB服务器即返回写入成功的信息，随后数据会被分布复制到更多的SimpleDB服务器上，而在分布完成之前无法查询到最新的数据。所以需要在应用中来处理这种查询延时导致的数据一致性问题。

3.数据聚合将需要更多的额外编码实现

SimpleDB没有实现诸如join，group by，sum/average，sort等，这些操作都需要在应用中来实现。

4.复杂查询和即席查询更难实现

SQL标准已经出现很多年，数据库引擎对于一些复杂的SQL查询做了足够多的优化。SimpleDB对于过于复杂的查询和条件不定的Ad hoc查询没有提供特别的支持，所以SimpleDB还不太适合数据仓库等OLAP应用。

5.数据聚合操作性能比RDBMS差

RDBMS引擎对于join,group by等聚合操作做了很多优化，优化器可以提供根据不同的情况使用诸如hash join,nested loop join等方式来实现。自己在应用中实现这些操作可能效率会不如成熟的RDBMS。当然，这一点有些牵强，在应用中实现有可能更坏也有可能更好，从分布式趋势来看，数据库将倾向于做越来越简单的数据存储，计算更多的应该交给前面的应用服务器来完成。

6.数据的导入导出，备份等操作更慢更繁琐

RDBMS提供了很多成熟的数据迁移和备份工具，这一点刚刚出世的SimpleDB等自然有不足，但这不是问题，只要有需求和时间，就会有工具。

7.SimpleDB并没有想象中的快

Todd Hoff在一篇文章中的数据：从SimpleDB的1000条记录的表中读取10条记录需要141ms，从100000条记录中读取10条记录需要266ms，而从1000000记录中读取10条需要433ms，这比RDBMS明显要慢很多。当然，对于分布式系统，数据量越大才能体现出优势。在小数据量的情况下，集中式比分布式肯定更有优势。

8.RDBMS也可以良好的可扩展性

列举了一些RDBMS的成功应用案例，如Facebook和Livejournal使用MySQL，myspace使用MS SQL Server，Salesforge.com使用Oracle。通过良好的应用设计、数据的垂直分割和水平分割、主从复制和群集等技术，传统的RDBMS也能实现不错的可扩展性，支撑大型的网站系统毫无问题。

9.超级可扩展性是一种过度设计

技术应该以适用为原则，过度设计是一种巨大的浪费。

10.SimpleDB非常有用，但也要用在合适的场合

SimpleDB并不是为了替代OLTP数据库而生的，它的key-value存储结构更加适用于处理半结构化的数据。好的产品也要用的合适的地方才能扬长避短。