bisal的专栏

Troubleshooting步骤：Troubleshooting与IO相关的等待：数据库性能调优方面一项关键的方法就是响应时间分析。找出时间都花费在数据库的哪些环节。时间是性能调优中最重要的属性。Troubleshooting I/O-related waitsA critical activity in Database Performance Tu

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

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

昨天有篇“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

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

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

当前应用时常会出现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执行，并

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

非常著名的Oracle官方文档汇总的下载地址：http://tahiti.oracle.com/另外，对于10g以前的若干安装版本当前官网已经没有提供下载地址了，但可以通过提交一个SR来寻求帮助。

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

解决IO问题的常用方法：        使用Statspack类似的工具对数据库响应时间分析之后，已经表明与IO相关的等待事件限制了系统性能，有许多的方法可以判断这种问题。        接下来的章节会介绍排查等待事件的方法。        有一些方法可以不用管特定的等待事件。在这个章节，会介绍和解释每个方法背后的概念和基本原理。通过对SQL的调优降低数据库的IO请求：   

与控制文件IO相关的等待事件：        这种等待事件通常产生于一个或多个控制文件的IO。像redo日志切换和检查点事件，都会产生频繁的控制文件访问。因此调优这些实践可以间接地影响这种等待事件。'control file parallel write'        这种等待事件通常发生于服务器进程正在更新所有控制文件副本的时候。如果这种等待事件占据大部分事件，那么需要检查

今天有同事询问Oracle在线浏览的手册是否可以下载，确实下载到本地浏览才是非常方便的，之前从@secooler大神这里找过下载链接，特此转载，以备查询，向大神致敬！@secooler转载地址：http://space.itpub.net/519536/viewspace-567429oracle不同版本的官方文档在线参考和打包下载地址汇总，罗列在这里，供你我参考。1.

与Redo日志IO相关的等待事件：        Redo日志活动期间会有很多的等待事件，而且他们大多是和IO相关的。最重要的两个就是‘log file sync’和‘log file parallel write’。        Oracle前台进程(或叫服务器进程)等待‘log file sync’事件，LGWR进程等待‘log file parallel write’。   

Buffer Cache与IO相关的等待事件：        这种等待事件的产生原因是包含DBWR进程和IO Slaves的Buffer Cache操作。'db file parallel write' , 'db file single write',  'write complete waits',  'free buffer waits'        如下文档会有相关更

使用索引快速全扫描(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()

续《表扫描与索引扫描返回的行数不一致》上篇文章主要介绍了如何从分析表得到的报错，以及trace中的信息，判断表返回的记录与索引返回记录不一致时的处理方式。下面这篇文章则介绍了针对ORA-1499进行问题排查的一些基本方法。OERR: ORA-1499 table/Index Cross Reference Failure - see trace file (文档 ID 14

某个应用最近总出现死锁，其中一些是因为报了索引和数据行存在不匹配的问题，MOS中有如下文档可以参考。ORA-1499. Table/Index row count mismatch(文档 ID 563070.1)现象：使用“validate structure cascade”分析表时报ORA-1499的错误，trace文件中包含“Table/Index row count m

最近在看一本《WEB全栈工程师的自我修养》一书，其中涉及到了npm这个词的意义，非常有意思。 一般人可能以为npm是Node Package Manager的缩写，但实际上不是这样的，npm不是Node Package Manager的首字母缩写，所以不能全大写。npm是“npm is not an acronym”(npm不是一个缩写)这个递归定义的简写。是不是很绕？呵呵。 递归定义是指