惜分飞 -- IT技术博客大学习 -- 共学习共进步！

• OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明

OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明

今天有朋友在群里面讨论oracle数据库最大可以存储的数据大小,下面根据官方文档提供的相关限制,大概估算出来oracle数据库最多可以存储的数据量

现在有个需求,需要使用exp/imp导入11g的数据库数据到9i中,解决这个问题一般来说想到三种方法思路,一个个尝试(其实从高版本服务端支持低版本客户端的原则,可以大概的猜测出使用9i的客户端处理该问题) 方法1:导出导入都使用11g客户端这个错误是版本不兼容导致:PLS-00302: component ‘SET_NO_OUTLINES’ must be declared 方法2:11g客户端导出,9i客户端导入方法3:9i客户端导出,9i客户端导入解决setSegmentation fault异常终止通过一系列的实验证明,需要把11g的数据导入到9i中,需要使用9i的客户端进行,其中exu9defpswitches视图需要重建,否则会出现setSegmentation fault异常,导致导入失败.

• sql_id和hash value的部分转换

从oracle 10g开始引进了sql_id，在老版本的oralce中,要表明一条sql,一般使用hash value，而在10g及其以后版本中一般建议使用sql_id,从9i的sp和10g的awr中也可以看出.对于Library Cache对象,Oracle使用MD5算法进行哈希,生成一个128位的Hash Value,其中低32位作为HASH VALUE显示,SQL_ID则取了后64位.既然hash value和sql_id之前存在着这样的关系,那么我们就可以通过函数实现两者的部分转换(因为最终取值长度不同,所以不能完全转换) 1.查询sql_id和hash value 2.oracle自带函数转换sql_id to hash value 3.自己编写函数sql_id to hash value 4.hash value 转换为部分 sql_id

• 记录一次比较棘手数据库恢复要点

在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下.

• 常驻连接池(Database Resident Connection Pool)

数据库驻留连接池是Oracle Database 11g的一个新特性，专门为了解决在需要支持大量连接的环境对可扩性的迫切需求而设计的。数据库驻留连接池把数据库服务器进程和对话汇合起来(这样的组合称之为池服务器)，通过从单主机或不同主机发出的多个应用软件进程的连接进行共享。由一个连接代理(Connection Broker)进程控制着数据库后台进程中的池服务器。连接代理会持续的连接客户并对客户进行验证。当需要进行某种数据库活动时，客户将请求连接代理提供池服务器，使用完毕后再将它们释放以供其他客户重新使用。当池服务器处在使用当中时，相当于一台专用服务器。对于来自常驻通道中的客户端连接请求，连接代理会为其选择一个合适的池服务器，并把客户端请求交给该池服务器处理，不再干涉。此后客户通过和该池服务器的直接对话来完成所有的数据库活动。当客户完成请求任务释放池服务器后，连接代理将重新接管该池服务器。

• 提高短连接监听性能方法测试

如果在数据库短连接过程中发现监听是瓶颈的时候,可以考虑使用多个监听+tns 负载均衡,从一定程度上缓解监听瓶颈.如果是11g数据库可以考虑使用其心功能DRCP,从而很大程度上提高短连接过程中数据库的效率.因为DRCP还属于11g的新功能稳定性不知道如何?使用该功能前,请一定要做好相关测试工作.如有可能还是建议从应用层面尽可能的使用长连接,提高数据库会话效率.

• 恢复备份控制文件避免resetlogs方式打开数据库

在很多时候,我们需要使用备份控制文件恢复数据库,在恢复完成后,准备打开库,很多人知道这个时候如果要打开这个库,需要使用resetlogs操作,虽然在oracle 10g及其以后版本中在恢复的时候可以跨越resetlogs操作,但是很多时候大家还是希望使用备份的控制文件能够正常的open一个库,而不是resetlogs.这里通过实验展示使用备份控制文件正常open库的过程.

• DB2数据迁移之load

一.load原理性知识 1.为什么要使用LOAD load不需要写日志(或很少日志),不做检查约束和参照完整性约束,不触发Trigger,锁的时间比较短,因此特别适合大数据量的导入. 2.load过程分为4个阶段 load/build/delete/index copy. load阶段是将源文件parser成物理数据存储的格式,直接装入到页中,而不通过db2引擎,load阶段会检查表定义,违背定义的数据不会装入到表中. build阶段建议索引（如果装入表有索引的话）,会检查唯一性约束,违背了唯一性的数据会在delete阶段删除. index copy阶段将index数据从指定的临时表空间拷贝到初始的表空间里. index copy只适应于allow read access场景.load的4个阶段会记录在messages文件里.

• 执行计划中常见index访问方式

近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本篇文章仅仅是为了测试hint对index的影响,而不是说明走各种index方式的好坏.参考: INDEX FULL SCAN vs INDEX FAST FULL SCAN 创建表模拟测试 TABLE ACCESS FULL 从上面的执行计划中可知,此时走了全表扫描. 由于我们需要查询的列为object_id,因此理论上只需要读取索引就应该可以返回所有数据,而此时为什么是全表扫描呢？

• ASM HEADER 备份与恢复

最近遇到几次ASM HEADER出问题导致DATA GROUP 不能正常的MOUNT,是的数据库不能正常工作,从来带来了无穷的麻烦,这个时候心想,如果我做了ASM HEADER的备份该多好啊,可惜世上没有后悔药,建议大家检查下自己的ASM库,ASM HEADER是否已经做了备份,如果没有请及时处理下.这里试验提供了dd和kfed备份和恢复ASM HEADER。

• 利用scn增量备份实现数据库增量恢复

使用rman基于scn实现数据库增量恢复是在dg中修复gap的时候常见的方法,其实该方法也可以使用常规的增量恢复,通过人工控制,实现数据库的某种特殊的业务需求(特殊的数据迁移).处理思路主要是获得备库的数据文件最小scn(这个scn可能是通过全备恢复或者增量恢复产生),然后基于该SCN实现数据库增量备份,然后利用该备份进行增量恢复.

• DB2日志参数介绍和修改归档模式

DB2日志参数介绍和修改归档模式

• oracle 9i数据库存在大量ora_j0**进程

1.发现多个ora_j0**进程可以发现进程重启非常频繁,大概1分钟重启一次，启动ora_j0**的个数为20个 2.其他参数 3.对cjq进程做10046 4.查看cjq的10046文件发现大量的process startup等待，而且两次批量运行之间的时间间隔在1分钟左右。通过O记的大力帮助,终于找出了该问题的原因:Bug 4339922: CJQ PROCESS WAKE UP JOB QUEUE PROCESSES EVERY 1 MINUTES.(THERE IS NO JOBS).因为9i的版本oracle不再提供新补丁支持,ora_j0**相关进程不停重启不太占用系统和数据库资源,在不能升级数据库的情况下,可以考虑设置job_queue_processes到一个合适值,然后忽略该问题。跟踪ORACLE非当前会话利用oradebug释放被删除文件空间查找V$PARAME

• hint指定index的深入理解

创建一个表，含有位图index和b-tree index 无index hint 这里因为object_id列可能有null值，所以不会使用b_tree_t_xifenfei索引，预料之中事件 index hint b_tree_t_xifenfei 这里因为object_id列可能有null值，所以不会使用b_tree_t_xifenfei索引，这里的疑惑是：就算不会使用b_tree_t_xifenfei index也不应该会使用BITMAP_T_XIFENFEI index，因为使用这个的cost会大于全表扫描 index hint 一个无效index 这里使用了一个无效的index，也使用了BITMAP_T_XIFENFEI，让人更加的感觉奇怪