有一个应用，在访问clob时抛出异常如下：

FATAL ERROR IN TWO-TASK SERVER: error = 12152
*** 2008-07-17 18:28:43.912
ksedmp: internal or fatal error
ORA-12571: TNS:packet writer failure

RDBMS:9206，查metalink，证实为一个未公开的bug，为了挠过该bug，将clob类型的字段改成long类型，结果访问还是有问题，当长度超过一定的长度时，proc程序就只能读取前4000个字符，因为应用已经发布，修改代码已经来不急。查看了一下long字段的内容，发现文字内容很少的，大部分都是html的格式代码，只需要找出长度超过4000的记录，去掉该部分html代码应用就可以恢复正常；但怎么在long字段中找到超过4000字符记录呢？

 查看全文

相对于10gR2而言，11gR1中stream的新功能更是令人期待，比如：同步捕获（synchronous capture）功能，已经脱离日志挖掘的范畴；stream性能顾问（stream performance advisor）可以识别stream拓扑中的瓶颈、分离与合并stream的目标站点(对于复杂的stream环境可以提高其可用性及可维护性)，跟踪LCRs的状态等、支持透明数据加密等、比较与同步共享的数据库对象（当复制环境中名称相关的表数据不一致时，可以用dbms_comparison包来同步）。。。

 查看全文

SCOPE & APPLICATION
-------------------

This is intended as a reference for anyone involved in database tuning.

At the moment we consider the following PX wait events as idle:
- "PX Idle Wait"
- "PX Deq: Execution Msg"
- "PX Deq: Table Q Normal"
- "PX Deq Credit: send blkd"
- "PX Deq: Execute Reply"
- "PX Deq Credit: need buffer"
- "PX Deq: Signal ACK"
- "PX Deque wait"

在dataguard环境中，经常发现standby库的pxxx进程的trace文件中有这样的信息，查了metalink，官方的解释：并不是bug或者错误，而是因为在primary database执行了不可恢复的操作导致的，解决的办法特简单，在primary database上执行以下操作：

 查看全文

The setting for the SHARED_POOL_SIZE parameter determines the amount of memory required to manage the instance. The setting for this parameter is also used to determine the amount of space that is allocated for extent storage. The default value for this parameter is suitable for most ASM environments.

 查看全文

Oracle 以变长格式存储数字数据。所有数字数据均以科学计数法存储[scientific notation]，使用 1 字节存储指数[exponent]，最多 20 字节存储尾数[mantissa]。最终存储的数字数据受限于 38 位精度限制。且 Oracle 不会存储数字首端及末端的 0。举例来说，数字 412 在存储时的格式可以理解为 4.12 x 10²，Oracle 使用 1 字节存储指数（2），使用 2 字节存储尾数的三位有效数字（4，1，2）。存储负数时，符号也需要占用存储空间。

 查看全文

经常见到有人在系统设计时用GUID或MD5产生的32位字符串做主键，即使一些按日期产生的业务编码如2001010100001这样的字符串，都用varchar2来存储，总觉得不是很好，如果数据量不大的话，也无可厚非，但如果运用于存储海量的数据，那将会造成存储成本的巨增，请看下面的测试：

 查看全文

如果你的系统中，通过statspack report或awr report，发现这样的SQL执行比较频繁，而且test表的记录数比较多，test表中附合status = '1'的记录数也非常多，占test表记录数90%的比例吧，从statspack report或awr report可以发现该SQL的逻辑读会相当大，假定该表没有任何索引，那DBA该如何着手进行SQL的优化呢？
SELECT seller_id
FROM (SELECT * FROM (SELECT seller_id, max(gmt_create) FROM test WHERE status = 1 GROUP BY seller_id)
ORDER BY gmt_create DESC)
WHERE rownum <= 10;

 查看全文

在11g中，优化器有两种模式：普通模式与调化模式。优化器在普通模式下，当SQL被执行时，查询优化器将生成SQL的执行计划，如果SQL的可选路径很多，优化器必须是限制时间内，选择一个合适的执行计划；当优化器在调优模式下，优化器需要执行额外的分析去判断优化器在普通模式下产生的执行计划是否有可能被改进，此时优化器输出的不是一个执行计划，而是一系列的动作，根据调优的原理、产生一个更优化的执行计划，优化器需发花费一定的时间去调优单个的sql，自动调优的优化器每次查询都是硬解析。

 查看全文

系统变更会影响SQL的执行计划，比如数据库升级，优化参数调整，表结构变更，索引维护（创建，删除，重建），统计信息收集等，Oracle为了预防系统变更所引起的不良后果，特推出SPA，SPA做为RAT(Real Application Test)的一部分，可以消除一些不知预知的错误，Oracle提供dbms_sqlpa包来实现系统变更前后的性能分析，SPA主要应用在以上方面：

 查看全文

在11g中，Real Application Testing（RAT）是一个独立的收费选项，所以当我们需要订购此项服务时，我们该了解该服务有那些限制，否则付了钱，发现有许多地方存在或多或少的冲突，有些冲突的消除可能要花费更大的成本，所以在上项目前，可行性技术研究是必不可少的，如果想使用RAT，需要关注现有的数据库系统是否涉及到如下技术：

 查看全文

在Oracle 11g，SMB是SPM的控制端，SMB是数据字典的一部分，SMB存储在sysaux表空间，SMB存储SQL语句日志，Plan Histories，以及SQL Profiles等，SMB允许每周清除一次未使用的SQL Plan & Log，SMB已经配置了自动存储空间管理。

 查看全文

在11g，oracle提供dbms_spm包来管理SQL Plan，SPM是一个预防机制，它记录并评估sql的执行计划，将已知的高效的sql执行计划建立为SQL Plan Baselines，SQL Plan Baseline的功能是保持SQL的性能而不必关注系统的改变。

 查看全文

从11g开始，表与索引的统计信息收集完毕后，可以选择收集的统信息立即发布，也可以选择使新收集的统计信息处于pending状态，待确定处于pending状态的统计信息是安全的，再使处于pending状态的统计信息发布，这样就会避免一些因为收集统计信息立即发布而导致SQL执行计划走错的灾难。

 查看全文

在11g中，dbms_stats package提供了组合列的统计信息的收集，如果在where条件中使用了组合列进行查询，则优化器将会得到更准确的统计信息，进而输出执行计划时，可以输出更接近与真实数据的统计结果，11g的Extended Statistics包含了组合列与表达式统计信息的收集，表过式统计信息收集主要是针对函数索引字段，下面就组合列统计信息的收集做一下测试：

 查看全文

在oracle 10g中，优化统计信息的收集是通过scheduler job来自动完成的，dba可以通过dbms_scheduler package的enable procedure与disable procedure来启动与关闭，在oracle 11g中，oracle提供了全新的package dbms_auto_task_admin来完成统计信息的收集工作，测试脚本如下所示：

 查看全文

五 如何在DB中配置DRCP？
在11g中，系统默认包含了一个连接池：SYS_DEFAULT_CONNECTION_POOL，这个池默认被创建，但默认该池是不启动的，如果要启动默认的连接池，必须显式地执行启动DRCP的命令，oracle提供dbms_connection_pool package来执行这个工作，如果连接池被显式地启动，必须显式地被停掉，当实例宕掉时，如果DRCP是活动的，则实例启动时，DRCP也将自动实动。
启动DRCP需要以下步骤：
A 用sysdba权限连接到sqlplus
B 执行exec dbms_connection_pool.start_pool();
C 查看DRCP的状态

 查看全文

三Dedicated Servers,Shared Servers与DRCP的内存需求
一般情况下，由于每个会话需要消耗400k的内存，每个进程需要消耗4m的内存，现在我们以DRCP的pool size是100，shared server的shared server进程是100为例，假如有5000个客户端连接到这些环境，则这些主机的内存分配如下：
A Dedicated Server
Memory used = 5000 X (400 KB + 4 MB) = 22 GB
B Shared Server
Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB
Out of the 2.5 GB, 2 GB is allocated from the SGA.
C Database Resident Connection Pooling
Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB

 查看全文

在oracle中，进程的频繁创建是一个比较消耗资源的开消，在11g之前，oracle提供专用器进程与共享服务器进程供用户选择适合自己的进程机制，在11g中，oracle又推出DRCP(database resident connection pool)，类似于sqlrelay那种轻量级中间件的进程机制为客户服务，DRCP适用于web application（比如php/apache），可以提供成千上万的连接，使用DRCP可以共享主机资源。

 查看全文

在11g中，很多功能oracle都引导用户通过OEM来操作，但喜欢用API的dba，照样可以写脚本来完成自己的工作，下面给大家介绍一下database replay的配置方法，database replay可以捕捉整个数据库的负载，并且传递到需要进行测试数据库上，然后重演负载以测试系统调优后的效果，当然也可以为升级硬件进行压力测试。

 查看全文

在oracle 11g以前的版本中，如果对大表进行全表扫描，通过v$session_wait可以看到wait event是：db file scattered read；在11g中，如果对大表进行全表扫描，通过v$session_wait可以看到wait event是：direct path read；也就是说，在11g中，大表全表扫描是将数据块直接读入会话的pga区域。

 查看全文

在11g以前的版本,SQL的运行情况可以通过监控v$session_longops来了解,当某个操作执行时间超过6秒,就会被v$session_longops感知,通常可以监控到比如全表扫描,全索引扫描,哈希联接,并行查询等;在11g中,当sql并行运行时,马上会被real-time monitor到,当sql单进程运行时,如果运行时间超过5秒,它也会被监控到。

 查看全文

11g在awr report方面，还是增加了一些吸引眼球的地方，比如增加了对OS等主机配置的报告，对于dba来讲，在接手一个新环境时,或做现场服务时，该报表将会简少一些额外的工作，比如报表中已经可以显示主机名，操作系统，CPU个数，物理内存等，最让人关注的还是增加了主机负载的一些情况，具体变化请看下文：

 查看全文

在11g以前的版本中,如果表上存在未提交的事务,则对表进行DDL操作将失败,在11g中,这个限制已经被取消啦,执行ADD COLUMN操作时,并不会受未提交事务的影响,另外,ADD COLUMN还有一个增强,就是在一个非常大的表上执行ADD COLUMN xxx DATATYPE DEFAULT yyy NOT NULL时,它不会再去将默认值更新到表中已经存在的记录,这样改进的好处是非常大的,DBA对表结构的变更将更加容易,而且不会产生大量的library cache lock/pin等,更不会阻塞事务,它是怎么做到的呢?

 查看全文

从最初学习9iR2的stream，以及10gR1，10gR2的stream，到现在的11gR1，可以说oracle在stream上面压了很大的成钱，stream也越来越得到用户的接受，在11gR1中，stream比之前的版本也有较大的改进，比如同步捕获，合并的捕获与应用进程等，以下就简单地列下新增的功能点，感兴趣的可以自己看文档。。。

 查看全文

在11g中，oracle提供了一个新的可动态调整的参数ddl_lock_timeout，该参数允许存在未提交的事务的表上，执行DDL操作，如果事务在ddl_lock_timeout允许的时间内提交，则DDL操作将会成功，否则就会报ORA-00054错误，如果对该表执行ADD COLUMN操作，则会直接提交表上发生的未提交的事务，所以用11g时，有些东西还是要注意的，当然也不排除这是11g的一个bug哦。。。

 查看全文

从理论上讲，db file sequential read是没有办法避免的，即是高端存储，对于同样次数的db file sequential read，主要是响应时间上有较大的下降，所以解决db file sequential read等待，需要从以下两个方面来想办法：

 查看全文

在测试9iR2,10gR1,10gR2的stream时,非常希望能够有种同步capture的机制,该同步capture机制与log-based real-time capture机制是不同的,它应该是一种内部触发的机制,比如当有活动事务时,DB引擎判断该表配置有stream的同步capture标志,就可以直接把dml打包成LCRs并压入队列...

 查看全文

收到al*.log报ORA-00600: [17113], [0x000000000]错误，查看*.trc文件后，发现有个开发人员通过pl/sql developer查询生产库引起的，开发人员没有查询生产库的权限，后来才知开发人员通过开发库中指向生产库的db link执行了一个查询，结果就触发了一个ORA-600错误。。。

 查看全文

在批量处理数据时，比如从上亿条记录的表中删除上1000万条数据，不仅要考虑对undo的影响，还要考虑对redo，对磁盘i/o，锁、阻塞等的影响，在某种意思上讲，同样的任务，执行的sql次越少，总的消耗的时间就越少。。。

Senior dba

技能要求
1、精通Oracle数据库的运行机制
2、精通Oracle数据库的管理，经验丰富者优先
3、精通备份与恢复原理，精通Data Guard
4、精通SQL&PL/SQL的编程
5、熟悉linux/aix操作系统的使用
6、熟悉shell&perl编程

其它要求
1、全日制本科以上学历
2、能吃苦耐劳，抗压能力强
3、具有良好的团队合作精神
4、良好的沟通能力