===========================================================
留给你思考：分区问题
===========================================================
===========================================================
ORA-01503 recreate ctl
===========================================================
35 '/oradata/NEDCPRD/data02/lob_data01.dbf', 36 '/oradata/NEDCPRD/data02/retek_data01.dbf', 37 '/oradata/NEDCPRD/index02/retek_index01.dbf' 38 CHARACTER SET UTF8 39 ; CREATE CONTROLFILE set DATABASE "RWMS905" RESETLOGS NOARCHIVELOG * ERROR at line 1: ORA-01503: CREATE CONTROLFILE failed ORA-01159: file is not from same database as previous files - wrong database id ORA-01110: data file 11: '/oradata/NEDCPRD/index01/ind1_01.dbf'
---copy files
===========================================================
lru_file_repage
===========================================================
当lru_file_repage设置为0的时候, 如果client pages的数目大于minperm,将选择file pages被替换.如果小于minperm,任何没有被referenced的page将被替换.
当lru_file_repage设置为1的时候,如果client pages的数目介于minperm和maxclient之间,
LRU算法将参考repage的计数. 最近没有被referenced的page将被stolen. defalut value
===========================================================
How to Use DBMS_STATS to Move Statistics to a Different Database
===========================================================
Doc ID: Note:117203.1
Subject: How to Use DBMS_STATS to Move Statistics to a Different Database 查看全文
Subject: How to Use DBMS_STATS to Move Statistics to a Different Database 查看全文
===========================================================
Top Partitioned Tables Issues
===========================================================
I. Creating Partitioned Tables
Using the Range Partitioning Method
-----------------------------------
Range partitioning maps rows to partitions based on a range of column values.
This type of partitioning is best suited when dealing with data that has logical
ranges into it can be distributed by. For example, months of the year, or
a numeric value. Performance is best when the data is evenly distributed across
the range. If partitioning by range causes partitions to vary dramatically in
size because of unequal distribution, you may want to consider one of the other
methods of partitioning.
When creating range partitions, you must specify the method as "RANGE", the
partitioning column(s) in the RANGE, and the partition boundaries. 查看全文
Using the Range Partitioning Method
-----------------------------------
Range partitioning maps rows to partitions based on a range of column values.
This type of partitioning is best suited when dealing with data that has logical
ranges into it can be distributed by. For example, months of the year, or
a numeric value. Performance is best when the data is evenly distributed across
the range. If partitioning by range causes partitions to vary dramatically in
size because of unequal distribution, you may want to consider one of the other
methods of partitioning.
When creating range partitions, you must specify the method as "RANGE", the
partitioning column(s) in the RANGE, and the partition boundaries. 查看全文
===========================================================
奥运来了
===========================================================
3块金牌，加油
===========================================================
ksbsrv:no startup acknowledgement from forked process after 30 seconds
===========================================================
alert.log :ksbsrv:no startup acknowledgement from forked process after 30 seconds 查看全文
===========================================================
explain for dbms_stats
===========================================================
very important 查看全文
===========================================================
回收空间的建议
===========================================================
http://www.itpub.net/viewthread.php?tid=1032613&pid=11155684&page=1&extra=#pid11155684
===========================================================
Managing Partitions
===========================================================
===========================================================
Instance Activity Stats Section --statspack
===========================================================
recursive cpu usage = This component can be high if large amounts of PL/SQL are being processed. It is outside the scope of this document to go into detail with this, but you will need to identify your complete set of PL/SQL, including stored procedures, finding the ones with the highest CPU load and optimize these. If most work done in PL/SQL is procedural processing (rather than executing SQL), a high recursive cpu usage can actually indicate a potential tuning effort.
parse time cpu= Parsing SQL statements is a heavy operation, that should be avoided by reusing SQL statements as much as possible. In precompiler programs, unnecessary parting of implicit SQL statements can be avoided by increasing the cursor cache (MAXOPENCURSORS parameter) and by reusing cursors. In programs using Oracle Call Interface, you need to write the code, so that it re-executes (in stead of reparse) cursors with frequently executed SQL statements. The v$sql view contains PARSE_CALLS and EXECUTIONS columns, that can be used to identify SQL, that is parsed often or is only executed once per parse.
other cpu= The source of other cpu is primarily handling of buffers in the buffer cache. It can generally be assumed, that the CPU time spent by a SQL statement is approximately proportional to the number of buffer gets for that SQL statements, hence, you should identify and sort SQL statements by buffer gets in v$sql. In your statspack report, look at the part ‘SQL ordered by Gets for DB’. Start tuning SQL statements from the top of this list. In Oracle9i, the v$sql view contain a column, CPU_TIME, which directly shows the cpu time associated with executing the SQL statement.
查看全文
===========================================================
Select ..for update（nowait)
===========================================================
锁在用户修改之前就发挥作用：
Select ..for update（nowait)
Select * from tab1 for update
用户发出这条命令之后，oracle将会对返回集中的数据建立行级封锁，以防止其他用户的修改。
如果此时其他用户对上面返回结果集的数据进行dml或ddl操作都会返回一个错误信息或发生阻塞。
1：对返回结果集进行update或delete操作会发生阻塞。
2：对该表进行ddl操作将会报：Ora-00054:resource busy and acquire with nowait specified.
Select ..for update（nowait)
Select * from tab1 for update
用户发出这条命令之后，oracle将会对返回集中的数据建立行级封锁，以防止其他用户的修改。
如果此时其他用户对上面返回结果集的数据进行dml或ddl操作都会返回一个错误信息或发生阻塞。
1：对返回结果集进行update或delete操作会发生阻塞。
2：对该表进行ddl操作将会报：Ora-00054:resource busy and acquire with nowait specified.
原因分析
此时Oracle已经对返回的结果集上加了排它的行级锁，所有其他对这些数据进行的修改或删除操作都必须等待这个锁的释放，产生的外在现象就是其他的操作将发生阻塞，这个这个操作commit或rollback.
同样这个查询的事务将会对该表加表级锁，不允许对该表的任何ddl操作，否则将会报出ora-00054错误：:resource busy and acquire with nowait specified
===========================================================
MAXTRANS integer
===========================================================
Specify the maximum number of concurrent transactions that can update a data block allocated to the database object. This limit does not apply to queries. This value can range from 1 to 255 and the default is a function of the data block size. You should not change the MAXTRANS value from its default.
If the number of concurrent transactions updating a block exceeds the INITRANS value, then Oracle dynamically allocates transaction entries in the block until either the MAXTRANS value is exceeded or the block has no more free space.
The MAXTRANS parameter serves the same purpose in the PARTITION description, clusters, materialized views, and materialized view logs as in tables.
===========================================================
回味
===========================================================
回味 查看全文
===========================================================
resource_limit=true
===========================================================
SELECT * FROM DBA_PROFILES;
ALTER PROFILE PRO_1 LIMIT CPU_PER_CALL UNLIMITED;
===========================================================
Statistics Gathering: Frequency and Strategy Guidelines
===========================================================
===========================================================
vmstat
===========================================================
aix
System configuration: lcpu=36 mem=44031MB ent=18.00
===========================================================
再次遇到cache buffer chains
===========================================================
问题确实还难解决，尤其不允许停机的状况下。
生产系统约 1.7 T;
===========================================================
dba_2pc_pending
===========================================================
dbms_transaction.purge&tijiao
show parameter undo_suppress_errors=true
===========================================================
Multiple Buffer Pools
===========================================================
The KEEP pool
The role of the KEEP buffer pool is to cache those static or non-updating objects that have a lot of select activity for example, lookup tables and some indexes. Once the KEEP buffer pool is correctly sized, the blocks for objects assigned to this pool are never removed. As a result, access to the objects in this pool doesn’t require disk operation, greatly increasing the query performance. The famous DEPT table would be a good example of a reference table that would have little DML activity and can be cached in the KEEP pool.
The RECYCLE pool
The role of the RECYCLE buffer pool is just the opposite. It’s designed for those objects that will be accessed once, such as a full table scan on a large object, or objects that have many DML statements that won’t be referenced again by the application, such as transaction logs or audit trail type logs.
The DEFAULT pool
The DEFAULT buffer pool is really the area of the buffer cache that isn’t being used by the KEEP buffer pool or the RECYCLE buffer pool. All other objects not directed specifically at the KEEP buffer pool or the RECYCLE buffer pool will remain in the DEFAULT buffer pool. 查看全文
The role of the KEEP buffer pool is to cache those static or non-updating objects that have a lot of select activity for example, lookup tables and some indexes. Once the KEEP buffer pool is correctly sized, the blocks for objects assigned to this pool are never removed. As a result, access to the objects in this pool doesn’t require disk operation, greatly increasing the query performance. The famous DEPT table would be a good example of a reference table that would have little DML activity and can be cached in the KEEP pool.
The RECYCLE pool
The role of the RECYCLE buffer pool is just the opposite. It’s designed for those objects that will be accessed once, such as a full table scan on a large object, or objects that have many DML statements that won’t be referenced again by the application, such as transaction logs or audit trail type logs.
The DEFAULT pool
The DEFAULT buffer pool is really the area of the buffer cache that isn’t being used by the KEEP buffer pool or the RECYCLE buffer pool. All other objects not directed specifically at the KEEP buffer pool or the RECYCLE buffer pool will remain in the DEFAULT buffer pool. 查看全文
===========================================================
v$db_object_cache
===========================================================
本视图提供对象在library cache(shared pool)中对象统计，提供比v$librarycache更多的细节，并且常用于找出shared pool中的活动对象。
v$db_object_cache中的常用列：
l OWNER：对象拥有者
l NAME：对象名称
l TYPE：对象类型(如，sequence,procedure,function,package,package body,trigger)
l KEPT：告知是否对象常驻shared pool(yes/no)，有赖于这个对象是否已经利用PL/SQL 过程DBMS_SHARED_POOL.KEEP“保持”（永久固定在内存中）
l SHARABLE_MEM：共享内存占用
l PINS：当前执行对象的session数
l LOCKS：当前锁定对象的session数
瞬间状态列：
下列列保持对象自初次加载起的统计信息：
l LOADS：对象被加载次数。
示例：
1.shared pool执行以及内存使用总计
下列查询显示出shared pool内存对不同类别的对象
同时也显示是否有对象通过DBMS_SHARED_POOL.KEEP()过程常驻shared pool。
SELECTtype, kept, COUNT(*), SUM(sharable_mem)
FROM V$DB_OBJECT_CACHE
GROUPBYtype, kept;
2.通过载入次数找出对象
SELECT owner, name sharable_mem, kept, loads
FROM V$DB_OBJECT_CACHE
WHERE loads > 1ORDERBY loads DESC;
3.找出使用的内存超过10M并且不在常驻内存的对象。
SELECT owner, name, sharable_mem, kept
FROM V$DB_OBJECT_CACHE
WHERE sharable_mem > 102400AND kept = 'NO'
ORDERBY sharable_mem DESC;
===========================================================
reference
===========================================================
select name,1-(physical_reads/(db_blocks_gets+consistent_gets)) "hit_ratio" from v$buffer_pool_statistics where db_block_gets+consistent_gets>0
===========================================================
数据的命中率
===========================================================
select (1 - (sum(decode(name, physical reads, value, 0)) /
(sum(decode(name, db block gets, value, 0)) +
sum(decode(name, consistent gets, value, 0))))) * 100
"hit ratio"
from v$sysstat;
===========================================================
EBS中9个重要的视图
===========================================================
1）v$lock 给出了锁的信息，如type字段， user type locks有3种：TM，TX，UL，system type locks有多种，常见的有：MR，RT，XR，TS等。我们只关心TM，TX锁。 当TM锁时，id1字段表示object_id；当TX锁时，trunc(id1/power(2,16))代表了回滚段号。 lmode字段，session持有的锁的模式，有6种： 0 - none 1 - null (NULL) 2 - row-S (SS) 3 - row-X (SX) 4 - share (S) 5 - S/Row-X (SSX) 6 - exclusive (X) request字段，process请求的锁的模式，取值范围与lmode相同。 ctime字段，已持有或等待锁的时间。 block字段，是否阻塞其它锁申请，当block=1时说明这个session阻塞了别的session。
2）v$sqlarea 共享池中存储的sql和一些相关的信息，如累计的执行次数（executions），逻辑读（buffer_gets），物理读（disk_reads）等统计信息。 根据address和hash_value可以定位一条sql。sql_text字段存的这个sql的前1000个字符。查找整个的sql还需去v$sqltext或者v$sqltext_with_newlines。
3）v$session 所有当前session的信息，包括一些用户信息如username，terminal，program，logon_time等，command字段表示session执行的什么命令。 通过v$session.paddr=v$process.addr跟process相关，通过v$session.taddr=v$transaction.addr跟trancation相关。 通过sid可以到相关视图中查询与这个session相关的各种信息，如v$sesstat中有session的统计信息，v$sess_io中有session的io统计信息，v$session_wait中有session的等待信息，v$session_event中有session在一段时间内所等待的各种事件的信息。 根据lockwait字段可以查询当前正在等待的锁的相关信息： select * from v$lock where kaddr in (select lockwait from v$session where sid=&sid); (sql_address,sql_hash_value)，(prev_sql_addr,prev_hash_value) 根据这两组字段, 可以查询到当前session正在执行的或者最近一次执行的sql语句的详细信息： select * from v$sqltext where address = &sql_address and hash_value = &sql_hash_value;
4）v$sesstat 根据session id可以得到这个session的统计信息： select a.name,b.value from v$statname a,v$sesstat b where a.STATISTIC#=b.STATISTIC# and b.sid=&sid and b.value <>0 order by b.value;
5）v$session_wait --这部分抄袭 xzh的blog 根据session id可以得到这个session的等待情况。 event字段表示等待事件。 p1、p2、p3告诉我们等待事件的具体含义，如果wait event是db file scattered read，p1=file_id/p2=block_id/p3=blocks，然后通过dba_extents即可确定出热点对象；如果是latch free的话，p2为闩锁号，它指向v$latch。 P1RAW,P2RAW,P3RAW列对应P1,P2,P3的十六进制值；P1TEXT,P2TEXT,P3TEXT列对应P1,P2,P3列的解释。 --求等待事件及其对应的latch col event format a32 col name format a32 select sid,event,p1 as file_id, p2 as "block_id/latch", p3 as blocks,l.name from v$session_wait sw,v$latch l where event not like '%SQL%' and event not like '%rdbms%' and event not like '%mon%' and sw.p2 = l.latch#(+); --求等待事件及其热点对象 col owner format a18 col segment_name format a32 col segment_type format a32 select owner,segment_name,segment_type from dba_extents where file_id = &file_id and &block_id between block_id and block_id + &blocks - 1; --综合以上两条sql，同时显示latch及热点对象(速度较慢) select sw.sid,event,l.name,de.segment_name from v$session_wait sw,v$latch l,dba_extents de where event not like '%SQL%' and event not like '%rdbms%' and event not like '%mon%' and sw.p2 = l.latch#(+) and sw.p1 = de.file_id(+) and p2 between de.block_id and de.block_id + de.blocks - 1; --如果是非空闲等待事件，通过等待会话的sid可以求出该会话在执行的sql select sql_text from v$sqltext_with_newlines st,v$session se where st.address=se.sql_address and st.hash_value=se.sql_hash_value and se.sid =&wait_sid order by piece;
6）v$process 根据session id可以查到操作系统进程的信息： select * from v$process where addr in (select paddr from v$session where sid=&sid ); spid字段是操作系统进程号，可以用来进行 kill -9 spid 这么一个操作。 可以找到 unix命令 top 出来的最耗cpu资源的pid，根据pid最耗资源的sql： SELECT /*+ ORDERED */ sql_text FROM v$sqltext a WHERE (a.hash_value, a.address) IN ( SELECT DECODE (sql_hash_value, 0, prev_hash_value, sql_hash_value ), DECODE (sql_hash_value, 0, prev_sql_addr, sql_address) FROM v$session b WHERE b.paddr = (SELECT addr FROM v$process c WHERE c.spid = '&pid')) ORDER BY piece ASC /
7）v$transaction 根据session id可以查到当前session正在执行的事务信息： select * from v$transaction where addr in (select taddr from v$session where sid=&sid ); 看下面这两个字段可以看到事务进行到什么程度了： USED_UBLK NUMBER Number of undo blocks used USED_UREC NUMBER Number of undo records used 重复查询这两个值，可以看到变化，可以估计事务的进度，尤其是长时间的回滚操作，当这两个值为0，回滚也就完成了。
8）v$sort_usage temp表空间的使用情况，当temp表空间变得巨大的时候，根据session_addr可以得到session id，根据sqladdr和sqlhash可以得到正在执行的sql： select se.username,se.sid,su.extents,su.blocks*to_number(rtrim(p.value)) as Space,tablespace,segtype,sql_text from v$sort_usage su,v$parameter p,v$session se,v$sql s where p.name='db_block_size' and su.session_addr=se.saddr and s.hash_value=su.sqlhash and s.address=su.sqladdr order by se.username,se.sid;
9）v$sysstat 所有instance的统计信息。
===========================================================
如何在亿级记录表中创建索引
===========================================================
需要考虑的几个方面
1）创建的索引需要几个g的磁盘空间。
2）创建索引需要排序，使用pga_aggregate_target，要把这个值从200m加大到2g。
3）如果内存不够，需要temp表空间，则要把temp表空间加大到8g——itpub上有一个帖子说过，15亿条记录用了34g空间。
4）在线创建，时间会比较长。讨论后，停止这个表的操作，非online创建。
3. 实际操作过程
1）数据文件够，不扩展；temp数据文件扩展：
alter database tempfile '/bgdata/oracle/temp01.dbf' resize 8192m;
2）在workarea_size_policy=auto的情况下，改pga_aggregate_target=2048m。对于串行操作，一个session能使用的pga=min(5%pga_aggregate_target,100mb)，这样可以使得pga用到最大的值：
alter system set pga_aggregate_target=2048m;
3）因为这是一个比较长的过程，所以写脚本让后台运行：
nohup time createind.sh &
vi createind.sh
#!/bin/sh
sqlplus user/password <
exit
eof
4）创建过程中可以观察v$sort_segment，v$sort_usage看排序情况：
nohup time createind.sh &
vi createind.sh
#!/bin/sh
sqlplus user/password <
exit
eof
5）创建完成后，把tempfile和pga_aggregate_target改回原值：
alter database tempfile '/bgdata/oracle/temp01.dbf' resize 4096m;
alter system set pga_aggregate_target=500m;
查看全文
===========================================================
深度分析数据库的热点块问题
===========================================================
http://www.eygle.com/digest/2006/11/hotblock_analyze.html
热点块的定义
数据库的热点块，从简单了讲，就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的，但实际在数据库中，我们要去观察或者确定热点块的问题，却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的，我们需要了解一些数据库在这方面处理机制的特性。
数据缓冲区的结构
我们都知道，当查询开始的时候，进程首先去数据缓冲区中查找是否存在查询所需要的数据块，如果没有，就去磁盘上把数据块读到内存中来。在这个过程中，涉及到数据缓冲区中LRU链的管理（8i开始以接触点计数为标准衡量buffer冷热从而决定buffer是在LRU的冷端还是热端），关于这部分内容，从oracle concepts 中就能得到详尽的文档，我不准备去论述这部分内容，这也不是本文的重点。现在我们的重点是，到底进程是如何地去快速定位到自己所想要的block的，或者如何快速确定想要的block不在内存中而去进行物理读的。
我们仔细想一想，随着硬件的发展，内存越来越大，cache buffer也越来越大，我们如何才能在大量的内存中迅速定位到自己想要的block？总不能去所有buffer中遍历吧！在此数据库引出了hash的概念（oracle中快速定位信息总是通过hash算法的，比如快速定位sql是否在shared pool size中存在就是通过hash value来定位的，也就是说shared pool size中对象也是通过hash table来管理的），了解一点数据结构的基本知识就知道，hash 的一大重要功能就是快速地查找。举个最简单的例子，假设我们有一个hash table 就是一个二维数组a[200][100],现在有1000个无序数字，我们要从这1000个数字里面查找某个值是否存在，或者说当我们接收到某个数字的时候必须判断是否已经存在，当然，我们可以遍历这1000个数字，但这样的效率就很低。但现在我们考虑这样一种方法，那就是把1000个数字除以200，根据其余数，放在a[200][100]里面(假设相同余数的最大数量不超过100)，余数就是数组的下标。这样，平均来说一个数组a[i]里面可能有5个左右的数字。当我们要去判别一个数字是否存在的时候，对这个数字除以200(这就是一个最简单的hash算法)，根据余数i作为下标去数组a[i]中查找，大约进行5次查找就能判别是否已经存在，这样通过开辟内存空间a[200][100]来换取了时间(当然hash 算法的选取和hash table的大小是一个很关键的问题)。
明白了基本的hash原理之后，我们再来看oracle的block的管理。数据库为这些block也开辟了hash table，假设是a,则在一维上的数量是由参数_db_block_hash_buckets 来决定的，也就是存在hash table a[_db_block_hash_buckets ],从oracle8i开始，_db_block_hash_buckets =db_block_buffers*2。而一个block被放到哪个buckets里面，则是由block的文件编号、块号(x$bh.dbarfl、x$bh.dbablk对应了block的文件属于表空间中的相关编号和block在文件中的编号，x$bh是所有cache buffer的header信息，通过表格的形式可以查询)做hash 算法决定放到哪个bucket的，而bucket里面就存放了这些buffers的地址。这样当我们要访问数据的时候，可以获得segment的extent(可以通过dba_extents查到看，详细的信息来源这里不做探讨)，自然知道要访问的文件编号和block编号，根据文件和block编号可以通过hash算法计算出hash bucket,然后就可以去hash bucket里面去找block对应的buffer。
除此之外，为了维护对这些block的访问和更改，oracle还提供了一种latch来保护这些block。因为要避免不同的进程随意地径直并发修改和访问这些block，这样很可能会破坏block的结构的。latch是数据库内部提供的一种维护内部结构的一种低级锁，latch的生存周期极短(微秒以下级别)，进程加latch后快速的进行某个访问或者修改动作然后释放latch(关于latch不再过多的阐述，那可能又是需要另一篇文章才能阐述清楚)。这种latch数量是通过参数_db_block_hash_latches 来定义的，一个latch对应的保护了多个buckets。从8i开始，这个参数的default规则为:
当cache buffers 少于2052 buffers
_db_block_hash_latches = power(2,trunc(log(2, db_block_buffers - 4) - 1))
当cache buffers多于131075 buffers
_db_block_hash_latches = power(2,trunc(log(2, db_block_buffers - 4) - 6))
当cache buffers位于2052与131075 buffers之间
_db_block_hash_latches = 1024
通过这个规则我们可以看出，一个latch大约可以维护128个左右的buffers。由于latch使得对block的操作的串行化(9i中有改进，读与读可以并行，但读与写、写与写依然要串行)，很显然我们可以想到一个道理，如果大量进程对相同的block进程进行操作，必然在这些latch上造成竞争，也就是说必然形成latch的等待。这在宏观上就表现为系统级的等待。明白了这些原理，为我们下面的在数据库中的诊断奠定了基础。
如何确定热点对象
如果我们经常关注statspack报告，会发现有时候出现cache buffer chains的等待。这个cache buffer chains就是_db_block_hash_latches所定义的latch的总称，通过查询v$latch也可得到：
select">sys@OCN>select latch#,name,gets,misses,sleeps from v$latch where name like 'cache buffer%';
LATCH# NAME GETS MISSES SLEEPS
---------- ------------------------------ ---------- ---------- ----------
93 cache buffers lru chain 54360446 21025 238
98 cache buffers chains 6760354603 1680007 27085
99 cache buffer handles 554532 6 0
在这个查询结果里我们可以看到记录了数据库启动以来的所有cahce buffer chains的latch的状况，gets表示总共有这么多次请求，misses表示请求失败的次数(加锁不成功)，而sleeps 表示请求失败休眠的次数，通过sleeps我们可以大体知道数据库中latch的竞争是否严重，这也间接的表征了热点块的问题是否严重。由于v$latch是一个聚合信息，我们并不能获得哪些块可能存在频繁访问。那我们要来看另一个view信息，那就是v$latch_children,v$latch_children.addr记录的就是这个latch的地址。
select">sys@OCN>select addr,LATCH#,CHILD#,gets,misses,sleeps from v$latch_children
2 where name = 'cache buffers chains' and rownum < 21;
ADDR LATCH# CHILD# GETS MISSES SLEEPS
-------- ---------- ---------- ---------- ---------- ----------
91B23B74 98 1024 10365583 3957 33
91B23374 98 1023 5458174 964 25
91B22B74 98 1022 4855668 868 15
91B22374 98 1021 5767706 923 22
91B21B74 98 1020 5607116 934 31
91B21374 98 1019 9389325 1111 25
91B20B74 98 1018 5060207 994 31
91B20374 98 1017 18204581 1145 18
91B1FB74 98 1016 7157081 920 23
91B1F374 98 1015 4660774 922 22
91B1EB74 98 1014 6954644 976 32
91B1E374 98 1013 4881891 970 19
91B1DB74 98 1012 5371135 971 28
91B1D374 98 1011 5154497 990 26
91B1CB74 98 1010 5013796 936 18
91B1C374 98 1009 5667446 939 25
91B1BB74 98 1008 4673421 883 14
91B1B374 98 1007 4589646 986 17
91B1AB74 98 1006 10380781 1020 20
91B1A374 98 1005 5142009 1110 19
20 rows selected.
到此我们可以根据v$latch_child.addr关联到对应的x$bh.hladdr(这是buffer header中记录的当前buffer所处的latch地址)，通过x$bh可以获得块的文件编号和block编号。
select">sys@OCN>select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11);
DBARFIL DBABLK
---------- ----------
4 6498
40 14915
15 65564
28 34909
40 17987
1 24554
8 21404
39 29669
28 46173
28 48221
……………………
由此我们就打通了cache buffers chains和具体block之间的关系，那再继续下来，知道了block，我们需要知道究竟是哪些segment。这个可以通过dba_extents来获得。
select distinct a.owner,a.segment_name from
dba_extents a,
(select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ ------------------------------ ------------------
ALIBABA BIZ_SEARCHER TABLE
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA CMNTY_VISITOR_INFO_PK INDEX
ALIBABA COMPANY_AMID_IND INDEX
ALIBABA COMPANY_DRAFT TABLE
ALIBABA FEEDBACK_POST TABLE
ALIBABA IM_BLACKLIST_PK INDEX
ALIBABA IM_GROUP TABLE
ALIBABA IM_GROUP_LID_IND INDEX
ALIBABA MEMBER TABLE
ALIBABA MEMBER_PK INDEX
ALIBABA MLOG$_SAMPLE TABLE
……………………
我们还有另外一种方式
select object_name
from dba_objects
where data_object_id in
(select obj
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) ;
OBJECT_NAME
------------------------------------
I_CCOL2
RESOURCE_PLAN$
DUAL
FGA_LOG$
AV_TRANSACTION
COMPANY_DRAFT
MEMBER
SAMPLE
SAMPLE_GROUP
VERTICAL_COMPONENT
MEMBER_PK
SAMPLE_GROUP_PK
IM_BLACKLIST_PK
IM_CONTACT
IM_GROUP
CMNTY_USER_MESSAGE
CMNTY_VISITOR_INFO_PK
IM_OFFLINEMSG_TID_IND
OFFER
OFFER_PK
OFFER_EMAIL_IND
OFFER_DRAFT
CMNTY_USER_MESSAGE_TD_BSM_IND
CMNTY_MESSAGE_NUM_PK
BIZ_EXPRESS_MEMBER_ID_IND
……………………
到这里我们基本能找到热点块对对应的对象。但实际上还有另外一个途径来获取这些信息，那就是和x$bh.tch 相关的一种方法。对于8i开始oracle提供了接触点(touch count)来作为block是冷热的标志，在一定条件满足的情况下block被进程访问一次touch count 增加一，到某个标准之后被移动到LRU热端(关于touch count 在这里不做详细介绍，那又将是一大篇文章)。那在短时间内从某种意义上讲，touch count 大的block可能暗示着在当前某个周期内被访问次数比较多。
select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ ------------------------------ ------------------
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA MEMBER_PK INDEX
ALIBABA OFFER_DRAFT_GMDFY_IND INDEX
同上面一样还有这个方法
select object_name
from dba_objects
where data_object_id in
(select obj
from (select obj
from x$bh order by tch desc) where rownum < 11) ;
OBJECT_NAME
---------------------------------------------------
DUAL
MEMBER_PK
SAMPLE_GROUP_PK
CMNTY_USER_MESSAGE_TD_BSM_IND
OFFER_DRAFT_MID_GMDFY_IND
OFFER_MID_GPOST_IND
OFFER_DRAFT_PK
MEMBER_GLLOGIN_IND
OFFER_MID_STAT_GEXPIRE_IND
SAMPLE_MID_STAT_IND
10 rows selected.
到这里，我们寻找热点块和热点对象的工作算是完成了，但我们还并没有解决问题。
热点问题的解决
热点块和热点对象我们都找到了，但是我们该怎么来解决这个问题呢？一般来说，热点块会导致cache buffers chains竞争等待，但并不是说cache buffer chains一定是因为热点块而起，在特别情况下有可能是因为latch数量的问题导致的，也就是一个latch管理的buffers数量太多而导致竞争激烈。但是latch数量我们一般是不会轻易去设置的，这是oracle的隐藏参数。
实际上最有效的办法，是从优化sql入手，不良的sql往往带来大量的不必要的访问，这是造成热点块的根源。比如本该通过全表扫描的查询却走了索引的range scan，这样将带来大量的对块的重复访问。从而形成热点问题。再或者比如不当地走了nested loops的表连接，也可能对非驱动表造成大量的重复访问。那么在这个时候，我们的目标就是找出这些sql来并尝试优化。在statspack报告中，根据报告中sql列表，我们如果是通过dba_extents确定的热点对象而不是通过dba_objects确定的，则可以通过查找出的热点segment转换为对应的表，对于非分区的索引，index_name就是segment_name,通过dba_indexes很容易的找到对应的table_name,对于分区表和分区索引也能通过和dba_tab_partition和dba_ind_partitions找到segment和table的对应关系。通过这些table到statspack报告中去找相关的sql。
select sql_text
from stats$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like '%'||b.segment_name||'%' and b.segment_type = 'TABLE'
order by a.hash_value,a.address,a.piece;
SQL_TEXT
----------------------------------------------------------------
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT bizgroup.seq_grp_post.NextVal FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
SELECT bizgroup.seq_grp_user.NextVal FROM DUAL
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
select seq_Company_Draft.NextVal from DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
select seq_News_Forum.NextVal from DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
select seq_Biz_Member.NextVal from DUAL
select seq_Pymt_Managing.NextVal from DUAL
E= '+08:00' NLS_DUAL_CURRENCY = '$' NLS_TIME_FORMAT = 'HH.MI.SSX
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
select seq_offer_draft.NextVal from DUAL
select seq_Biz_Express_Category.NextVal from DUAL
20 rows selected.
当然这里是从statspack搜集的stats$sqltext中去找的(你可以在statspack的文本报告中去找)，实际上，我们可以直接在当前数据库中的v$sqlarea或者v$sqltext里面去找到这些sql，然后来尝试优化。
select sql_text
from v$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like '%'||b.segment_name||'%' and b.segment_type = 'TABLE'
order by a.hash_value,a.address,a.piece;
SQL_TEXT
----------------------------------------------------------------
SELECT NULL FROM DUAL FOR UPDATE NOWAIT
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT SEQ_IM_GROUP.nextval FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='BI
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
IMESTAMP_TZ_FORMAT='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRE
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
SELECT USER FROM DUAL
SELECT DECODE('A','A','1','2') FROM DUAL
18 rows selected.
除了优化sql外，当然对于热点的表或者索引来说，如果小的话，我们可以考虑cache在内存中，这样可能降低物理读提高sql运行速度(这并不会减少cache buffer chains的访问次数)，对于序列，我们可以对序列多设置一些cache。如果是并行服务器环境中的索引对象，并且这个索引是系列递增类型，我们可以考虑反向索引(关于反向索引这里就不过多地做介绍了)。
===========================================================
ORACLE初始化参数文件
===========================================================
1:在9i之前，参数文件只有一种，它是文本格式的，称为pfile，在9i及以后的版本中，新增了服务器参数文件,称为spfile,它是二进制格式的。这两种参数文件都是用来存储参 数配置以供oracle读取的，但也有不同点，注意以下几点：
1)pfile是文本文件，spfile是二进制文件；
2)对于参数的配置，pfile可以直接以文本编辑器打开手工配置，而spfile不行，必须在数据库启动后，通过sql命令进行在线修改，当然spfile也可用文本编辑器打开，把里面文本的内容复制出来放在pfile中，但决对不可以直接修改，直接修改后会使文件无法读取。
3)pfile配置改变后，要使用其生效，必须重新启动数据库，spfile的配置生效时限和作用域可以由修改参数的sql命令指定，可以立即生效，也可以不立即生效。当然有些参数的修改必须重启数据库才能生效；
4)可以用sql命令由pfile创建spfile,也可以由spfile创建pfile；
5)如果是手动创建数据库而不是通过DBCA，则开始创建数据库时，你只能定义pfile 。因为它是文本格式的；
1)pfile是文本文件，spfile是二进制文件；
2)对于参数的配置，pfile可以直接以文本编辑器打开手工配置，而spfile不行，必须在数据库启动后，通过sql命令进行在线修改，当然spfile也可用文本编辑器打开，把里面文本的内容复制出来放在pfile中，但决对不可以直接修改，直接修改后会使文件无法读取。
3)pfile配置改变后，要使用其生效，必须重新启动数据库，spfile的配置生效时限和作用域可以由修改参数的sql命令指定，可以立即生效，也可以不立即生效。当然有些参数的修改必须重启数据库才能生效；
4)可以用sql命令由pfile创建spfile,也可以由spfile创建pfile；
5)如果是手动创建数据库而不是通过DBCA，则开始创建数据库时，你只能定义pfile 。因为它是文本格式的；
现在一般普通生产库都采用spfile启动数据库，pfile确实没有用的理由了，感觉只有以下情况才会使用pfile：
1)入门学习时，为了理解初始化参数
2)创建数据库时，因为这时还没spfile
3)恢复数据库时
4)采用RAC的生产库中如果要共用spfile，可以建一个初始的pfile,然后在pfile指定spfile为共享设备文件
...............
查看全文
===========================================================
flash copy的概念
===========================================================
1.7T大约1个时解决copy 好
ds8100
===========================================================
topas命令详解
===========================================================
以下是各个部分表示的含义：
Cswitch：在监控期间每秒钟内容转换的次数；
Syscall：在监控期间每秒钟运行系统呼叫的总次数；
Reads：在监控期间每秒钟运行读系统呼叫的次数；
Writes：在监控期间每秒钟运行写系统呼叫的次数；
Forks：在监控期间每秒钟运行派生系统呼叫的次数；
Execs：在监控期间每秒钟运行执行系统呼叫的次数；
Runqueue：等待处理器空闲以便运行的线程平均数；
Waitqueue：等待分页完成的线程平均数；
Readch：在监控期间通过读系统呼叫每秒钟读出的字节数；
Writech：在监控期间通过写系统呼叫每秒钟写入的字节数；
Rawin：在监控期间通过TTYs每秒钟读入的裸字节数；
Ttyout：在监控期间每秒钟写入TTYs的字节数；
Igets：在监控期间每秒钟到节点查找例行程序的呼叫数；
Namei：在监控期间每秒钟路径查找例行程序的呼叫数；
Dirblk：在监控期间通过目录搜索例行程序每秒钟扫描到的目录块数；
PAGING部分显示的是分页每秒钟次数的统计：
Faults：在监控期间每秒钟发生的分页错误总数；
Steals：在监控期间被虚拟内存管理器每秒钟偷走的物理内存4k的帧；
PgspIn：在监控期间每秒钟从分页空间中读取的4k分页数；
PgspOut：在监控期间每秒钟写入分页空间的4k分页数；
PageIn：在监控期间每秒钟读取的4k分页数，这包括从文件系统读操作相关的分页活动，从这个值减去PgspIn的值就是每秒钟从文件系统读操作相关的分页活动数；
PageOut：在监控期间每秒钟写入的4k分页数，这包括向文件系统写操作相关的分页活动，从这个值减去PgspOut的值就是每秒钟向文件系统写操作相关的分页活动数；
Sios：在监控期间通过虚拟内存管理器得到的I/O请求数；
Momory部分显示的是实际内存和在使用中的内存：
Real,MB：以M为单位的实际内存；
％Comp：当前分配给计算分页片断的内存占实际内存的百分比。计算分页片断由分页空间产生。
％Nocomp：当前分配非计算分页片断的内存占实际内存的百分比。非计算分页片断包括那些文件空间，数据文件、可执行文件、或者共享库文件。
％Client：当前分配给用来缓冲远程挂载文件的内存占实际内存的百分比。
PAING SPACE显示分页空间的大小和使用率：
Size,MB：系统里所有分页空间的大小，以M为单位；
％Used：当前使用的分页空间占总空间的百分比；
％Free：当前空闲的分页空间占总空间的百分比。
CPU工具：
User％：显示运行的用户程序所占用的CPU百分比；
Kern%：显示运行的内核程序所占用的CPU百分比；
Wait%：显示等待IO操作所占用的CPU百分比；
Idel%：显示CPU空闲的百分比。
网络接口：
Interf：网络接口的名称；
KBPS：在监控期间每秒钟通过的以M为单位的总流量，这部分包括每秒钟接收和发送的总和。
I-Pack：在监控期间每秒钟接收到的数据包数；
O-Pack：在监控期间每秒钟发送的数据包数；
KB-In：在监控期间每秒钟接收到的字节数（以K为单位）；
KB-Out：在监控期间每秒钟发送的字节数（以K为单位）。
物理磁盘：
Disk：物理磁盘的名称；
Busy%：指明物理磁盘在活动状态的时间百分比；
KBPS：在监控期间每秒钟读写的字节数（以K为单位）；
TPS：每秒钟物理磁盘的数据传输量。一次传输指的是一次I/O请求；
KB-Read：每秒钟从物理磁盘读出的K字节数；
KB-Write：每秒钟向物理磁盘写入的K字节数。
WLM（负载管理）类：
％CPU Utilization：CPU的平均利用率；
％Mem Utilization：内存的平均利用率；
％Blk I/O：块I/O的平均利用率；
进程：
NAME：可执行程序的名称；
Process ID：进程的ID号；
％CPU Utilization：进程的CPU平均使用率，这个值指的是进程在生命周期中的平均使用率；
Paging Space Used：分配给进程的分页空间大小；
Process Owner：拥有这个进程的用户名；
Workload Management（WLM）Class：进程属于哪个WLM class。 查看全文
Cswitch：在监控期间每秒钟内容转换的次数；
Syscall：在监控期间每秒钟运行系统呼叫的总次数；
Reads：在监控期间每秒钟运行读系统呼叫的次数；
Writes：在监控期间每秒钟运行写系统呼叫的次数；
Forks：在监控期间每秒钟运行派生系统呼叫的次数；
Execs：在监控期间每秒钟运行执行系统呼叫的次数；
Runqueue：等待处理器空闲以便运行的线程平均数；
Waitqueue：等待分页完成的线程平均数；
Readch：在监控期间通过读系统呼叫每秒钟读出的字节数；
Writech：在监控期间通过写系统呼叫每秒钟写入的字节数；
Rawin：在监控期间通过TTYs每秒钟读入的裸字节数；
Ttyout：在监控期间每秒钟写入TTYs的字节数；
Igets：在监控期间每秒钟到节点查找例行程序的呼叫数；
Namei：在监控期间每秒钟路径查找例行程序的呼叫数；
Dirblk：在监控期间通过目录搜索例行程序每秒钟扫描到的目录块数；
PAGING部分显示的是分页每秒钟次数的统计：
Faults：在监控期间每秒钟发生的分页错误总数；
Steals：在监控期间被虚拟内存管理器每秒钟偷走的物理内存4k的帧；
PgspIn：在监控期间每秒钟从分页空间中读取的4k分页数；
PgspOut：在监控期间每秒钟写入分页空间的4k分页数；
PageIn：在监控期间每秒钟读取的4k分页数，这包括从文件系统读操作相关的分页活动，从这个值减去PgspIn的值就是每秒钟从文件系统读操作相关的分页活动数；
PageOut：在监控期间每秒钟写入的4k分页数，这包括向文件系统写操作相关的分页活动，从这个值减去PgspOut的值就是每秒钟向文件系统写操作相关的分页活动数；
Sios：在监控期间通过虚拟内存管理器得到的I/O请求数；
Momory部分显示的是实际内存和在使用中的内存：
Real,MB：以M为单位的实际内存；
％Comp：当前分配给计算分页片断的内存占实际内存的百分比。计算分页片断由分页空间产生。
％Nocomp：当前分配非计算分页片断的内存占实际内存的百分比。非计算分页片断包括那些文件空间，数据文件、可执行文件、或者共享库文件。
％Client：当前分配给用来缓冲远程挂载文件的内存占实际内存的百分比。
PAING SPACE显示分页空间的大小和使用率：
Size,MB：系统里所有分页空间的大小，以M为单位；
％Used：当前使用的分页空间占总空间的百分比；
％Free：当前空闲的分页空间占总空间的百分比。
CPU工具：
User％：显示运行的用户程序所占用的CPU百分比；
Kern%：显示运行的内核程序所占用的CPU百分比；
Wait%：显示等待IO操作所占用的CPU百分比；
Idel%：显示CPU空闲的百分比。
网络接口：
Interf：网络接口的名称；
KBPS：在监控期间每秒钟通过的以M为单位的总流量，这部分包括每秒钟接收和发送的总和。
I-Pack：在监控期间每秒钟接收到的数据包数；
O-Pack：在监控期间每秒钟发送的数据包数；
KB-In：在监控期间每秒钟接收到的字节数（以K为单位）；
KB-Out：在监控期间每秒钟发送的字节数（以K为单位）。
物理磁盘：
Disk：物理磁盘的名称；
Busy%：指明物理磁盘在活动状态的时间百分比；
KBPS：在监控期间每秒钟读写的字节数（以K为单位）；
TPS：每秒钟物理磁盘的数据传输量。一次传输指的是一次I/O请求；
KB-Read：每秒钟从物理磁盘读出的K字节数；
KB-Write：每秒钟向物理磁盘写入的K字节数。
WLM（负载管理）类：
％CPU Utilization：CPU的平均利用率；
％Mem Utilization：内存的平均利用率；
％Blk I/O：块I/O的平均利用率；
进程：
NAME：可执行程序的名称；
Process ID：进程的ID号；
％CPU Utilization：进程的CPU平均使用率，这个值指的是进程在生命周期中的平均使用率；
Paging Space Used：分配给进程的分页空间大小；
Process Owner：拥有这个进程的用户名；
Workload Management（WLM）Class：进程属于哪个WLM class。 查看全文
===========================================================
single-table hash cluster practise
===========================================================
copy here ,see below 查看全文
===========================================================
基于ORACLE数据库查询优化方法研究
===========================================================
随着数据库技术的发展 ，其应用越来越广泛，已逐渐成为现代计算机信息系统和计算机应用系统的基础和核心。基于数据库的联机事务处理（ＯＬＴＰ）以及联机分析处理（OLAP）银行、企业、 政府等部门最为重要的计算机应用之一，并作为电子政务、门户网站等应用系统底层数据管理的工具。
数据库最基本的任务是存储、管理数据，而终端用户唯一能看到的数据库特性就是其性能：数据库以何速度处理某一指定查询的结果，并且将结果返回到用户所用的工具和应用程序。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大、查阅新闻、 查看文件、 查询统计信息等。因此，数据库查询操作的效率是影响一个应用系统响应时间的关键因素。随着一个应用系统中数据的动态增长，数据量变大，数据库查询效率就会有所降低，应用系统的响应速度也随之减慢，尤其对于海量数据的管理和查询问题就更加突出，如何提高动态增长的数据库的查询效率就显得尤为重要。
目前通用的数据库产品有很多种，其中ORACLE数据库以其支持大数据库、多用户的高性能事务处理, 对业界各项工业标准的支持,完整的安全和完整性控制，支持分布式数据库利分布处理 具有可移植性、可兼容性和可连接性等突出优点倍受用户喜爱，应用较为广泛，在互联网数据库平台上处于领先地位、其Ｓｐａｔｉａｌ技术能更加有效地管理地理信息，实现海量空间信息的存储和管理。本文结合ORACLE数据库应用经验，从命中率提高、多表查询优化、大表查询优化和ＳＱL优化等四个方面阐述ＯＲＡＣＬＥ数据库查询效率提高的经验和方法。
查看全文
===========================================================
关于sort_area_size参数的设置
===========================================================
sort_area_size是当查询需要排序的时候，数据库会话将使用这部分内存进行排序，当内存大小不足的时候，使用临时表空间进行磁盘排序。由于磁盘排序效率和内存排序效率相差好几个数量级，所以这个参数的设置很重要。
当出现大量排序时的磁盘I/O操作时，可以考虑增加sort_area_size的值。sort_area_size是Oracle用于一次排序所需的最大内存数，在排序结束但是结果列返回之前，Oracle会释放sort_area_size大小的内存，但是会保留sort_area_retained_size大小的内存，知道最后一行结果列返回以后，才释放所有的内存。
会导致排序的语句有 Select DISTINCT , MINUS , INTERSECT , UNION 和 min()、max()、count() 操作；而不会导致排序的语句有 Update , 带BETWEEN子句的Select 等等。
监控内存和硬盘的排序比率，最好使它小于 .10，增sort_area_size
Select name, value FROM v$sysstat Where name IN ('sorts (memory)', 'sorts (disk)');
sorts (memory) 59310076
sorts (disk) 4789
===========================================================
复杂的retail系统
===========================================================
了解IBM p595/590/570机器中;
需要慢慢熟悉新系统:
和2层架构很不一样,目前还不知个别还是特殊化...
===========================================================
R12升级到RUP4之后DB做clone、autocfg报错 ORA-12705
===========================================================
在对db做clone或autocfg的时候遇到过ORA-12705 的错误，错误原因是由于环境变量 ORA_NLS10的设置在autocfg的时候会指向错误的位置，需要手工修改，之后找到log中未能正确完成的sql再次运行即可
metalink的solution如下：
Solution
1.
Make sure to have a valid backup
2.
In the environment file set:
ORA_NLS oa_var="s_db_oranls"
to:
<DB-ORACLE_HOME>/nls/data/9idata"
3.
Run the updated environment script
4.
Start the database and the applications tier processes
5..
In the context XML file set:
ORA_NLS oa_var="s_db_oranls"
to:
<DB-ORACLE_HOME>/nls/data/9idata".
5.
Run AutoConfig on the DB tier
===========================================================
影响数据仓库成功的十个关键因素
===========================================================
===========================================================
Managing Control Files
===========================================================
The current location of the controlfiles can be queried from the V$CONTROLFILE view, as shown below.
select name from v$controlfile;
NAME
---------------------------------------------------------------
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/control01.ctl
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/control02.ctl
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/control03.ctl
In order to rename or move these files we must alter the value of the control_files instance parameter.
show parameter control_files
NAME VALUE
---------------- ------------------------------------------ ------------------------------
control_files /u01/app/oracle/product/9.2.0/oradata/DEVSOL/control01.ctl, /u01/app/oracle/product/9.2.0/oradata/DEVSOL/control02.ctl, /u01/app/oracle/product/9.2.0/oradata/DE
To move or rename a controlfile do the following:
* Alter the control_files parameter using the ALTER SYSTEM comamnd.
* Shutdown the database.
* Rename the physical file on the OS.
* Start the database.
The following SQL*Plus output shows how this is done for an instance using an spfile. For instances using a pfile replace the spfile manipulation steps with an amendment of the parameter in the init.ora file.
ALTER SYSTEM SET control_files='/new_path/control01.ctl', '/new_path/control02.ctl', '/new_path/control03.ctl' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE!mv /old_path/control01.ctl /new_path/control01.ctl!mv /old_path/control02.ctl /new_path/control02.ctl!mv /old_path/control03.ctl /new_path/control03.ctl
STARTUP
Repeating the initial query shows that the the CONTROLFILES has been renamed in the data dictionary.
select name from v$controlfile;
===========================================================
Managing Logfiles
===========================================================
The current location of the logfiles can be queried from the V$LOGFILE view, as shown below.
SELECT member FROM v$logfile;
MEMBER
--------------------------------------------------------
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo01.log
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo02.log
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo03.log
To move or rename a logfile do the following:
* Shutdown the database.
* Rename the physical file on the OS.
* Start the database in mount mode.
* Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
* Open the database.
The following SQL*Plus output shows how this is done.
SHUTDOWN IMMEDIATE!mv /old_path/redo01.log /new_path/redo01.log
!mv /old_path/redo02.log /new_path/redo02.log
!mv /old_path/redo03.log /new_path/redo03.log
STARTUP MOUNT
ALTER DATABASE RENAME FILE '/old_path/redo01.log'' TO '/new_path/redo01.log';
ALTER DATABASE RENAME FILE '/old_path/redo02.log'' TO '/new_path/redo02.log';
ALTER DATABASE RENAME FILE '/old_path/redo03.log'' TO '/new_path/redo03.log';
ALTER DATABASE OPEN;
Repeating the initial query shows that the the logfile has been renamed in the data dictionary.
SELECT member FROM v$logfile;
SELECT member FROM v$logfile;
MEMBER
--------------------------------------------------------
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo01.log
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo02.log
/u01/app/oracle/product/9.2.0/oradata/DEVSOL/redo03.log
To move or rename a logfile do the following:
* Shutdown the database.
* Rename the physical file on the OS.
* Start the database in mount mode.
* Issue the ALTER DATABASE RENAME FILE command to rename the file within the Oracle dictionary.
* Open the database.
The following SQL*Plus output shows how this is done.
SHUTDOWN IMMEDIATE!mv /old_path/redo01.log /new_path/redo01.log
!mv /old_path/redo02.log /new_path/redo02.log
!mv /old_path/redo03.log /new_path/redo03.log
STARTUP MOUNT
ALTER DATABASE RENAME FILE '/old_path/redo01.log'' TO '/new_path/redo01.log';
ALTER DATABASE RENAME FILE '/old_path/redo02.log'' TO '/new_path/redo02.log';
ALTER DATABASE RENAME FILE '/old_path/redo03.log'' TO '/new_path/redo03.log';
ALTER DATABASE OPEN;
Repeating the initial query shows that the the logfile has been renamed in the data dictionary.
SELECT member FROM v$logfile;
===========================================================
Finding the Object
===========================================================
db file sequential read
db file scattered read
buffer busy waits
Use the following query to find the object being accessed:
SELECT segment_owner, segment_name FROM DBA_EXTENTS WHERE file_id = &p1 AND &p2 between block_id AND block_id + blocks - 1 ;
===========================================================
如何确定一条SQL为何没有使用MV进行查询重写
===========================================================
有时候我们在使用MV进行查询重写时，会发现某条SQL应该使用MV重写，但是却没有重写。没有进行查询重写的原因很多，要找出其中的原因，还是要花一些功夫的。为此，oracle提供了dbms_mview.explain_rewrite过程来帮助我们确定为何一条SQL语句没有进行查询重写。 查看全文
===========================================================
使用dbms_stats包收集统计数据
===========================================================
dbms_stats包问世以后，Oracle专家可通过一种简单的方式来为CBO收集统计数据。目前，已经不再推荐你使用老式的分析表和dbms_utility方法来生成CBO统计数据。那些古老的方式甚至有可能危及SQL的性能，因为它们并非总是能够捕捉到有关表和索引的高质量信息。CBO使用对象统计，为所有SQL语句选择最佳的执行计划。 查看全文
===========================================================
关于数据库与数据仓库的区别详细介绍
===========================================================
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
查看全文
===========================================================
ORADEBUG使用详解
===========================================================
今天有朋友问起,好久没用,也都忘了差不多了.
SQL> oradebug setmypid //This will set the current session's pid.
SQL> oradebug dump events 1 //This will dump the events information in the tracefile based on the level
SQL> oradebug tracefile_name //This will return the trace file generated for this event.
查看全文
===========================================================
histogram与10053
===========================================================
histogram是oracle为cbo提供更精确的成本估计而设计的一种直方图数据。histogram能提供列的数据分布，每次分析表后列的分布信息将会被保存在统计表里面，分析时默认的histogram size是75，意思就是采用75个buckets来表示数据分布。
histogram分为2种类型，基于高度的histogram和基于值的histogram 查看全文
histogram分为2种类型，基于高度的histogram和基于值的histogram 查看全文
===========================================================
ORACLE的表分析策略
===========================================================
ORACLE的表分析策略 查看全文
===========================================================
ORACLE EBS 11i安装（后）常见问题
===========================================================
因一开发朋友问,故转贴.
查看全文