ANBOB™

今天遇到了一个奇怪的问题，有一个表空间无法删除，开始删除提示表空间内有对象，加上INCLUDING CONTENTS选项级连删除又报
ORA-01561: failed to remove all objects in the tablespace specified，查一些系统视图该对象还不存在

早接到电话说从sqlserver同步过来的数据在oracle 应用没查到，我查询同步job发现失败了，job所调用的procedure 生成了错误编号ORA-02291
procedre中代码较多，决定用errorstack快速定位一下sql

ERROR at line 1:
ORA-01461: can bind a LONG value only for insert into a LONG column
ORA-06512: at line 4

Operating system dependent. Limited by maximum operating system file size; typically 2^22 or 4 MB blocks

今天发现了这个问题，分析记录一下问题是这样子的，有一个表记录7亿，要在表上建索引，临时表空间已分配32G，DB DEFAULT BLOCK SIZE 8K，建索引时报了这个错误

exp,imp到其他9i数据库里出现部分数据变成了 46588.21 ,只因为指定了buffer

linux/unit 系统中查看cpu系统负载，都会先看一下这个参数，这个值在uptime 或ps 中都有

该视图记录任何的是操作时间超过6秒的，但是要注意并不是所有的超过6秒的记录都会在这里

table_name chain_cnt sta
———————– ———– ——-
ICME_SIMULATE_QA_STATUS 501443 YES

The RETURNING INTO clause allows us to return column values for rows affected by DML statements. The following test table is used to demonstrate this clause.

block_row_dump:
tab 0, row 0, @0x819
tl: 2061 fb: –H-F–N lb: 0x0 cc: 3
nrid: 0x0180005e.0
col 0: [ 2] c1 02

无论是行链接还是行迁移，都会影响数据库的性能。Oracle在读取这样的记录的时候，Oracle会扫描多个数据块，执行更多的I/O。

Level 0 停用SQL跟踪，相当于SQL_TRACE=FALSE
Level 1 标准SQL跟踪，相当于SQL_TRACE=TRUE
Level 4 在level 1的基础上增加绑定变量的信息
Level 8 在level 1的基础上增加等待事件的信息

Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 26,173 42.3
latch: cache buffers chains 21,954 4,041 184 6.5 Concurrency

shared pool 由perm，libary cache,row catch(dictionary catch),reserved area(保留),free area 组成。
…

合并列有很多方法，如聚焦函数、自定义函数利用游标分组、ROW_NUMBER() and SYS_CONNECT_BY_PATH 、还有10g后的wm_concat、及11G后新增函数..

owi (oracle wait interface)从oracle 7开始提供，开始是为了帮助oracle开发人员查询oracle性能，后来对外开放，帮助oracle用户的管理者和开发者分析数据库各模块的所需要时间
可以从metric中查看各命中率

OS Watcher简称OSW，用于收集并归档操作系统cpu,memery,disk io等相关信息的工具，是oracle提供的，OSW内部是使用操作系统提供的命令来收集数据，它可以放在后台定期间隔一段时间自动收集，并可以设定数据保留时间

列出一个目录里的的文件名，插入一个临时表中 包加java的两种方式

dbms_scheduler 是从10g开始用来替换dbms_job,它除了调用procedure还可能调用os命令或无名pl/sql块，而且在调用上更灵活，下面一例