ITPub博客

从timestamp到SCN的转换函数：SQL> select timestamp_to_scn(to_timestamp('2007-12-11 09:00:00','YYYY-MM-DD HH24:MI:SS')) from dual;TIMESTAMP_TO_SCN(TO_TIMESTAMP('2007-12-1109:00:00','YYYY-MM-DDHH24:MI:SS'))--------------------------------------------------------------------------36383520从SCN到timestap的转换函数：SQL> select scn_to_timestamp('36383520') from dual;SCN_TO_TIMESTAMP('36383520')--------------------------------------------------------------------------11-12月-07 09.00.00.000000000

之前的控制文件备份中提及到oracle推荐配置RMAN控制文件自动备份。当数据库结构发生改变或在RMAN每次成功完成备份之后，控制文件都会自动备份。这确保了nocatalog下，最新的备份对于数据库是可知的（信息存储在controlfile里）。那么，下面的步骤来模拟数据库遭到破坏，只留下之前的pfile初始化文件（1），数据文件备份（2）及controlfile自动备份（3），通过重建数据库来完成恢复。这里的原数据库为非归档运行，RMAN为nocatalog。首先要知道原数据库的DBID，本例为：1259705794C:>rman恢复管理器: Release 10.2.0.1.0 - Production on

控制文件有N多，且互为备份！单独丢失一个至N-1个，都可通过从初始化文件中删除相应项或通过复制其他完好的控制文件来使数据库正常工作。若是全丢了，实属不测！可根据以下两方面来恢复：情况1，除控制文件外，数据文件和redologs完好（一致）。换句话说，也就是数据库的datafile本身而且和redo log是一致的。这样控制文件的恢复很简单！只需要从之前的controlfile backup to trace中的脚本建立新的控制文件即可（控制文件里对数据文件及联机日志文件位置的描述需要跟现实环境同步）。若没有trace文件，手工写一个脚本也可以。因为同步，之

HP GL580 Server*5HP 500G2 1.2TDell 2950*2ORACLE RAC 10G 2Nodes , IBM Websphere Cluster 2Nodes, BI Server+Interface Server:| that's all[@more@]

今天在一次简单的通过远程服务器sqlplus连接RACD集群中的实例竟然失败：SQL*Plus: Release 10.1.0.4.2 - Production on 星期二 7月 24 10:13:07 2007Copyright (c) 1982, 2005, Oracle. All rights reserved.SQL> conn sys/racdb@racdb sysdbaERROR:ORA-12154: TNS: 无法解析指定的连接标识符 as后经过调查，原来罪魁是新近安装的ORACLE_BI套件，由于它的安装，导致了使用的客户端的环境变量发生变化，后安装的BI套件变成了默认的。所以，所使用的sqlplus程序和tnsname文件等一系列东东都变成了BI那一套,由于从未配置过到达RAC的连接，

SnapShot Control File（快照控制文件）是用来同步recovery catalog或备份当前控制文件时来使用。它的使用避免了RMAN操作对各节点的控制文件的频繁读写。在RAC环境中，该快照文件不需要在节点间共享，而仅在执行RMAN操作的节点上可用即可。 对于每个实例来说，在实例恢复所需要的归档日志，备份文件都要可访问，这样，把归档和备份(database recoverer area)置于各实例均能访问的位置是一个简单而方便的选择，如共享的文件系统。[@more@]

Shared Pool结构使用来实现SQL共享，减少代码硬解析等，从而提高数据库性能。但是，使用或是管理不当，很可能带来额外的负担或相反的作用。伴随着日常不合理使用的加剧，如数据库中存在大量的硬解析，不停的请求分配Free的Shared Pool内存，Shared Pool会产生很多碎片，从而导致搜索Free List的时间变长。另一方面，不合理的使用也会增加串行的的的Shared Pool Latch的等竞争。这种锁机制也往往成为性能的瓶颈。所以，可能造成这种性能低下的原因包含(数据仓库环境除外，且鼓励使用literal values来代替绑定变量，从而优化器可以更正确的制

Buffer Cache是缓存从磁盘中读取的信息的，使得Oracle需要的信息能够在内存中找到从而避免了代价昂贵的磁盘I/O。为了实现这个目标，原则上就需要尽量确保访问频率高的信息在buffer中而不被那些很少用到的或是只有一小部分有用而却占用了大量内存的内容冲掉。而且，Buffer Cache的大小也匹配于上面描述的需求的。为了满足上面提到的原则，就不得不了解下Oracle Buffer Cache的管理机制。BufferCache中的内存由WriteList（写链表）和Least Recent Used List(最近最少使用链表)组成。前者包含那些还没有被写道磁盘上的脏缓存，后者包括空闲缓

最近正在进行第一轮的开发数据库重构工作！由于当时的开发是步进式的，为了应用程序测试及调试的便利，一些完整性约束并未建立起来。而后台存储过程中却有大量的完整性约束的校验及及联删除的编码实现。这不禁让我产生了这样的疑问：数据库完成性约束是强壮的，值得信赖的！那手工的硬编码来做这些工作是否有必要呢？思考中~~ 我想，通过手工编码的方式来进行完整性约束的维护的优势之一就是可以反映业务规则，返回用户容易理解的错误信息。这也许比捕获异常后系统返回的sqlerrm要更友好一些。而很显然，使用数据库完整性约束特性（外键）

这两天一直在看一本书，震撼大奖得主《数据库重构》。选择在现在一个时间阶段来研习它，用意在于和调优的学习相结合，增加思维的广度。回忆起一年前参加IBM的RationalRUP及OOAD培训，一些观点和书中提倡的不谋而合。抛开技术实现不谈，单是在数据库领域重构的观点，的确颇有见解，也是大势所趋！没有一个DBA能否认在数据库开发与管理的各个阶段不是始终处在变化之中的。只不过有些问题在有些时候是被认为的刻意的忽略掉了！调优亦是如此，若调优发生在一个架构混乱的数据库上，效果也一定会大打折扣的。这一点，在国内的项目上恐怕尤为突出

自己认为Oracle-Managed Files不是多么的吸引人而只不过是为了为了方便文件系统的管理而已。OMF是建立在OS文件系统层之上的，所以对于RAW设备来说是不适合的。 更重要的是，当实现管理便利性的同时，失去的却是对I/O优化的干预能力。以下三个初始化参数决定DB是否使用OMF特性：DB_CREATE_FILE_DESTDB_CREATE_ONLINE_LOG_DEST_nDB_RECOVERY_FILE_DEST对于第一个参数DB_CREATE_FILE_DEST来说，它决定了SYSTEM和SYSAUX及UNDO和TEMP表空间数据文件的位置。对于除UNDO外前两个文件，默认数据文件为100M,且可自动扩展。对于UNDO,为10M，也可自动

转眼间，参加工作2年了。回想当时对人生第一个职位的定位和判断，有些庆幸，我不得不承认，我对能从毕业就全身心的接触到Oracle数据库，且可以全天候学习Oracle的工作环境很满意。作为blog的开篇，回忆过去和展望未来总是少不了的。那就先回忆过去好了。刚入职自己的确什么都不会，对Oracle数据库的理解仅仅停留在大学为数不多没有撬的那两节课Oracle选修课了。幸好遇到了我们开发团队的Team Leader,他的鼓励和指导给了我很大的帮助。人是需要懂得感恩的。而对于节约了我职业奋斗时间的人来说，更是如此。自那时起，Oracle数据库功底扎实的