2013年10月_bisal(Chen Liu)

原创一次删除还是分批删除

今天有位同事说“传言一次删除量大，是更慢”，这句话有对的地方，但重要的是问个为什么，只有知道了它的原因才能更好地使用Oracle提供的技术。我个人的理解是：删除量大小主要受限于UNDO表空间，因为执行DELETE每条记录时会将原始数据(镜像)放到UNDO中缓存，以防回滚，若UNDO空间小，一次删除量大，则会可能出现UNDO表空间不足的报错(ORA-30036: unable to ex

2013-10-25 14:44:20 2571

原创 Oracle官方文档下载与旧版本下载

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

2013-10-24 18:27:45 2886

原创应用长时间未调用后再次调用出现hang的情况

之前某应用就存在长时间不调用，再次调用时处于hang，等待10分钟返回3113的连接错误。今天正好同事也问了个相同的问题，也是应用长时间不调用就出现这种情况。以前对于这种问题进行过排查，但一直未解决，针对今天的这个系统的问题，还是按照老方法检查，1. 检查应用日志，确实长时间等待后报3113的错误。2. 检查数据库的PROFILE中idle_time参数，此处设置的是D

2013-10-23 18:45:35 1604

翻译 How to Tell if the I/O of the Database is Slow - 2

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

2013-10-22 18:19:37 2085

翻译 How to Tell if the I/O of the Database is Slow - 1

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

2013-10-21 22:51:15 1666

翻译 Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read'

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

2013-10-20 22:18:22 1980

翻译 High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access

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

2013-10-19 22:59:04 1751

翻译 "log file sync"等待事件-2

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

2013-10-18 17:36:28 2577

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

2013-10-17 09:09:12 1972

原创 ORA-02396: exceeded maximum idle time, please connect again的原因

一般为了防止过多活动的session占用资源，可以对允许连接到数据库的session个数，已连接到数据库的session空闲时间等进行限制(当然也可以对尝试连接次数等其它很多内容进行限制)。方式就是可以通过创建一个profile配置，然后将这个profile配置赋给每个用户。要使用这种限制的前提是将resource_limit这个参数设置为TRUE。alter

2013-10-16 09:30:58 10377

翻译续《表扫描与索引扫描返回的行数不一致》

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

2013-10-15 09:52:45 2159

原创 Proc中使用char数组、VARCHAR数组和char变量进行DELETE操作具体行数的细微区别

EXEC SQL BEGIN DECLARE SECTION;char a[10000][3];VARCHAR b[10000][31];char c[3];EXEC SQL END DECLARE SECTION;...int delete_rows=10000;...1. CHAR类型数组变量EXEC SQL for :delete_rows

2013-10-14 18:04:35 3284

翻译表扫描与索引扫描返回的行数不一致

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

2013-10-14 13:39:46 3510

翻译使用索引快速全扫描(Index FFS)避免全表扫描的若干场景

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

2013-10-13 22:29:25 5722

翻译与IO相关的等待事件troubleshooting-系列9

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

2013-10-12 08:32:18 1959

翻译与IO相关的等待事件troubleshooting-系列8

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

2013-10-11 23:07:07 1938

翻译与IO相关的等待事件troubleshooting-系列7

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

2013-10-10 10:24:16 1495

翻译与IO相关的等待事件troubleshooting-系列6

'db file parallel read' 当Oracle从多个数据文件并行读到内存(PGA或Buffer Cache)的非连续缓冲时，可以看到这种等待事件。在恢复操作或为了优化而预处理缓冲(代替执行多个单块读)时也会有这种等待事件。如果这种等待事件的事件占据大部分，可以按照“db file sequential read”的处理方法。Dire

2013-10-08 12:11:04 1803

翻译与IO相关的等待事件troubleshooting-系列5

'db file scattered read' 这是另一种常见的等待事件。他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续("scattered")缓存的时候。这种读一次最大值是DB_FILE_MULTIBLOCK_READ_COUNT。这种典型场景像全表扫描(Full Table Scans)和全索引快速扫描(Fast Full Indexscans

2013-10-07 18:16:54 1756

翻译与IO相关的等待事件troubleshooting-系列4

与数据文件IO相关的等待事件：接下来的等待事件是与数据文件的IO操作时产生的。'db file sequential read' 这是一种最常见的IO相关的等待。大多数情况下，他指的是单块读，例如索引数据块或通过索引访问的表数据块，也能在读取数据文件头块时看到这种等待事件。在更早的版本中，这种等待事件也会产生于从磁盘的排序段通过多快读的方式读入Buffer Cache

2013-10-07 16:21:55 1260

翻译与IO相关的等待事件troubleshooting-系列3

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

2013-10-05 19:58:27 1883

翻译与IO相关的等待事件troubleshooting-系列2

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

2013-10-04 20:04:40 1809

翻译与IO相关的等待事件troubleshooting-系列1

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

2013-10-03 19:02:22 1669

翻译一篇关于调优的概念性文章

今天看了一篇关于调优的概念性文章(61998.1： Introduction to Tuning Oracle7 / Oracle8 / 8i / 9i )。文章的目的是为了可以快速知晓执行过程中哪里花费了较多的时间，而不是关注不同统计数据的含义。更加关注实际。1. 为什么需要调优tuning？通常我们关注的是用户响应时间或批量作业的处理时间。也许是某天当中若干

2013-10-02 20:13:45 1699

原创 db file sequential read等待事件

最近某个应用的AWR中总显示“db file sequential read“等待事件位于top 5之首，下面检索下MOS关于这个等待事件的说明。等待事件: "db file sequential read" Reference Note (文档 ID 34559.1) 这种等待事件是一种IO读请求相关的等待。与”db file scattered read“不同，因

2013-10-01 23:33:03 16628

bisal的专栏