bisal的专栏

近来XX应用充分暴露出开发人员最初只关心功能，未考虑性能的问题，夜维、OLTP应用均出现了不同程度的与数据库相关的性能问题。这个应用所在磁盘的IO较差，原因在于这块磁盘较旧，已进入更换的流程，但短期内还不能更换，对应用是个极大的隐患。而且也出现过某段时间IO非常差，导致应用处理速度非常缓慢。针对与IO相关的性能问题，MOS有篇文章(223117.1)介绍的就是与IO相关的trouble

最近碰见了一个sqlplus登陆报错的问题，我一开始排查问题的方向就错了，不得已，还是请教了dbsnake大师，对于这么一个小问题，就像“小罗的不看人传球”般解决了问题，有因才有果，对于任何事情都成立。当然，我也不是第一次受挫了，归根结底，还是碰见的问题少，对于一些基础原则性知识掌握不够，不能从现象中直接看出本质，导致了方向性上的错误，急也没用，慢慢积累吧，所以还是要总结一下，避免下次再犯同样的错误

在上一章介绍expdp/impdp时曾使用过DIRECTORY这个概念，下面再简单说明下DIRECTORY的点点滴滴。MOS上对DIRECTORY的解释(266875.1)：(1)、基于服务端 vs 基于客户端DIRECTORY变量指出了expdp导出数据泵或impdp导入数据泵将dump文件、log文件以及SQL文件(仅适用于impdp)写到什么路径。因为导出数据泵和导入数据泵都

LOBs，或Large Objects字段，是Oracle中用于处理存储非字符数据推荐的一种字段类型，例如mp3，video，图片，和long字符串数据。二进制大对象，或BLOBs，字符大对象，或CLOBs，能够存储TB的数据。LOB列有许多相关的属性，每个LOB列属性可以使用“LOB (lobcolname) STORE AS ...”这种语法来描述。一个包含LOBs字段

昨天同事说有个测试库无法登录了，用PLSQL Developer登陆后提示：ERROR:ORA-00604: error occurred at recursive SQL level 1ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEMORA-02002: error while writ

前几天有位同事问到exp/imp是否涉及到版本问题，我认为，只要是软件，都会涉及到高低版本的兼容性问题，Oracle也是软件，自然也是这样。简单的实验：exp工具版本：10g导出的source数据库版本：9ibash-4.1$ exp x/x@x tables=T file=/home/x/t.dmpExport: Release 10.2.0.4.0 - Producti

问题现象：测试库使用如下方式创建索引：create index IDX_ANA_OFFICE on ANA (OFFICE_CITY, OFFICE_NO)  tablespace IDX  pctfree 10  initrans 2  maxtrans 255  storage  (    initial 128K    next 128K    m

今天QQ有问个问题，说有个应用报错3113，按照常规，让其检查了：1、用户profile是否设置了idle_time参数，没有。2、应用与数据库之间有防火墙超时设置，没有。于是又问他是所有应用都报错，还是某个报错，反馈说是一个SQL，用到了full join。我觉得这个是SQL语法问题，和3113连接断开应该没有关系啊？于是又让他看alert文件有什么记录，反馈说有个报错：“O

当前应用时常会出现deadlock的alert记录，关于如何判断与解决deadlock的问题，有一些介绍性的文章值得阅读。How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1507093.1)        当Oracle检测到死锁后，会取消当前检测到死锁的SQL执行，并

当前应用时常会出现deadlock的alert记录，关于如何判断与解决deadlock的问题，有一些介绍性的文章值得阅读。How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1507093.1)        当Oracle检测到死锁后，会取消当前检测到死锁的SQL

IO的类型：平均响应时间直接关联到具体的IO类型：1. 读或写2. 单块或多块        单块IO，指一次只读一个块。例如，当一个session等待一个单块IO时，典型的等待事件就是“db file sequential read”，表明正在等待需要的块。        多块读指的是一次读多个块，从2到128个Oracle块不等，依赖于块的大小与操作系统设置。通常一个多块请

系统变慢的原因有很多，有时是因为SQL，有时是因为硬件，有时又可能是系统，就如前几篇文章介绍的，AWR是一个查找问题原因的重要手段，同时OSWatcher等工具也是排查系统问题必不可少的方法。当然系统变慢，也需要知道他的主要现象，是整体慢，还是局部慢，是一直慢，还是瞬时慢。How to Tell if the I/O of the Database is Slow (文档 ID 127

昨天有篇“db file sequential read”的介绍，还有一篇类似的：Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read' Operations (文档 ID 1475825.1)诊断“db file sequential rea

最近某些系统AWR的top 5中“Db File Sequential Read”占据的时间百分比非常大，通常这种等待事件是一种正常的。但当前系统性能是有些问题的，并发量大，有些缓慢，因此需要判断这种等待事件是否能够减少。MOS有几篇关于这种等待事件的介绍，这是其中一篇。High Waits on 'Db File Sequential Read' Due to Table Looku

“log file sync”有三个参数：P1 = buffer#P2 = 未使用P3 = 未使用buffer#这个buffer编号(在日志缓冲区中)的所有改变必须刷新到磁盘，写操作的完成保证了交易COMMIT的执行，即使实例crash也会保证COMMIT。因此LGWR的等待就是刷新这个buffer#。等待时间：这种等待完全依赖于LGWR写出所有必要的red

“log file sync”是等待事件中非常常见的一种，他排在AWR的top5中有时是正常情况，有时则需要格外注意。昨天也听了一次Oracle的网络研讨会，介绍的是AWR相关的分析，从中学习到最重要的一点，就是对于AWR报告中若干信息的判断不能独立地看，需要综合起来，一个参数值大，不一定代表有问题，也可能是正常的，需要具体问题具体分析，其实和日常生活是一样的，头疼，不一定是感冒，也可能是缺少睡眠

使用索引快速全扫描(Index FFS)避免全表扫描(FTS)(文档 ID 70135.1)什么使用使用Index FFS比FTS好？Oracle 8的Concept手册中介绍：1. 索引必须包含所有查询中参考到的列。2. Index FFS只能通过CBO(Index hint强制使用CBO)获得。3. Index FFS使用hint：/*+ INDEX_FFS()

这两天做性能测试碰见一个问题，比较有意思。一条SQL，使用了绑定变量，查看V$SQLAREA发现version_count是2， 查看V$SQL，发现有两条记录，分别对应了0和1两个child cursor： 再查看这两个child cursor对应的执行计划： child cursor：0----------------------------------------------------