|
# 42638
Chi
来自: Mexico
|
|
|
 To: Eygle
I found the solution.
By reviewing a reference about the large_pool_size, it suggested that "alter system set disk_asynch_io=FALSE scope=spfile;" may help to speed up the RMAN, so i did and "alter system set large_pool_size=32M;". Tried a partial and a full database incremental level 0 and 1 backup, and it worked much faster now to finished my 32G database. The only question I concern is about whether the change of the asynch IO will affect other processes in Oracle. I maintain the same aio0 configuration on OS level.
From: Chi
2007.01.20 07:47
|
|
|
|
|
# 42634
Chi
来自: Mexico
|
|
|
To: Eygle
According to the result of the Backup Reports of the EM control (web form), the output rate varied from 11k up to 700K.I will tried to take out the "compressed". I also found on web that someone mentioned the slow of RMAN due to the setting of the AIX aio0 (asynchronous I/O), checked by the lsattr -El aio0.However, I did not know what is the proper values for AIX 5.3L, a lcpu=4 smt enabled, 4 HDs, p550 machine.Each change needs reboot the box
From: Chi
2007.01.18 05:20
|
|
|
|
|
# 42633
oracle 初段
|
|
|
To:
盖老师：
我想问问关于这个排序的问题，如果我查询的数据量不大，完全可以在通过内存排序来完成，那么查询结果返回给我是从buffer cache读的数据还是直接从排序区中读的数据呢？oracle在进行排序时，是把整个的数据块读到内存，我这样理解对吗？
2 ,共享池中的dictionary cache 中存放的是一些什么信息？
期待回答！谢谢
From: oracle 初段
2007.01.17 16:13
|
|
|
 |
|
 |
 |
|
 |
|
|
To: oracle 初段
从PGA，排序在你的PGA中完成，你测试一下就能明白多一点:
SQL> create table t as select * from dba_users;
Table created.
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> select * from t order by username;
PARSING IN CURSOR #1 len=68 dep=0 uid=0 oct=42 lid=0 tim=18134204370315 hv=1346161232 ad='e554cd0'
alter session set events '10046 trace name context forever,level 12'
END OF STMT
EXEC #1:c=0,e=25758,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=18134204359003
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1650815232 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 7431559 p1=1650815232 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=33 dep=0 uid=0 oct=3 lid=0 tim=18134211823578 hv=1202041768 ad='106e4fe0'
select * from t order by username
END OF STMT
PARSE #1:c=0,e=21119,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=18134211823565
BINDS #1:
EXEC #1:c=0,e=218,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=18134211823977
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1650815232 p2=1 p3=0
WAIT #1: nam='db file sequential read' ela= 56 p1=1 p2=26514 p3=1
FETCH #1:c=0,e=454,p=1,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=18134211824551
WAIT #1: nam='SQL*Net message from client' ela= 1992 p1=1650815232 p2=1 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1650815232 p2=1 p3=0
FETCH #1:c=0,e=121,p=0,cr=0,cu=0,mis=0,r=14,dep=0,og=4,tim=18134211826802
dictionary cache 的内容随便文档上都有讲。
From: eygle
2007.01.17 17:15
|
|
|
 |
|
 |
|
|
# 42631
pz
|
|
|
To: eygle
修改表空间参数时,AUTOEXTEND子句可以用在修改本地管理的表空间吗?
From: pz
2007.01.16 23:07
|
|
|
|
|
To: pz
当然可以了，这个试一下不就知道了。
From: eygle
2007.01.17 15:55
|
|
|
|
|
# 42629
Chi
来自: Mexico
|
|
|
To: Eygle
Which table can I used to find the wait event?I tried the v$session_wait, v$session and someone mentioned the v$session_longops, In previous two, all I could see was
SPID EVENT SEC_WAIT STATE CLIENT_INFO
-------- ------------------------------ ---------- ---------- -----------------------
897246 RMAN backup & recovery I/O 6 WAITING rman channel=ORA_DISK_1
did not understand the meaning?My last one full backup (this time I used the EM to run it) finally finished during the weekend, took 4.5 hours.More strangely, all datafiles backup into only one outfile, 927Mb ( my other test on RHEL3 form several of them), in addition to controlfile and archive backups.
From: Chi
2007.01.15 22:47
|
|
|
|
|
To: Chi
这个等待就是意味着备份I/O等待，要看具体等了多少时间。
1.你可以看看备份时I/O速度达到多少?
2.你可以尝试去掉压缩选项，看看I/O速度以及备份时间。
From: eygle
2007.01.17 15:37
|
|
|
|
|
# 42628
oracle 初段
|
|
|
To:
盖老师：
看了您的书感觉受益匪浅，不过还有写地方看不懂，请教一下
.1,您在书中提到 使用索引并不是最佳选择,不如读取较大的表中的大量数据,全表扫描可能会明显快于索引扫描.我想问一下您在实际的处理一些实际问题时通常认为多大的表属于大表,具体多少条记录,或者多少兆就可以认为是一个大表了?
2,直接路径读通常发生在oracle直接读数据到pga时,这个读取不需要经过sga.oracle 对数据的处理都是在data buffer cache 中进行的,怎么会不需要经过sga呢?这一点感觉不理解,希望盖老师给解释一下.如果需要排序的话,oracle是不是会把记录读到排序区进行排序?是否在数据查询时只要存在排序就会导致直接路径读?
3,系统一般产生的redo，多少算是很多？ 有没有一个定性的衡量指标来判定？avg.redo write size = (redo block written/redo writes)*512bytes
= (93853/14572)*512 bytes
= 3k 这个平均值过小了，我想问一下，根据你的经验，一般系统avg.redo write size 达到多大的值就可以认为该值过小？
期待您的指教！
谢谢
From: oracle 初段
2007.01.15 19:38
|
|
|
|
|
To: oracle 初段
1.我没有说"索引并不是最佳选择"吧?我说，并非在所有情况下索引都是最佳选择。大表和小表，我记得书中有说吧。至于多大的表算大，要根据SQL来判断的。如果仅从感觉上，现在至少百万以上的表才能算作大表吧。
2.排序要通过内存，可是当发生磁盘排序时，将磁盘上排好序的数据返回给用户，此时的读不需要再经过buffer cache了吧?
3.你可以计算一下，Oracle最常见出发Redo写的条件有1/3满，3秒超时，1M脏数据，如果以512K计算redo log buffer，如果3k写一次，写完512k要170次，你看这个小不小，对不一下缺省条件就知道个大概了。
From: eygle
2007.01.17 15:29
|
|
|
|
|
eygle.com
我要留言
回复
编辑
