eygle.com   eygle.com
eygle.com  
 
留言簿 - Powered by eYgLe.Com
eygle.com 我要留言
坚韧卓绝之人，必能成就万事
昵称
内容 页: 1 - << < 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 > >> - 310
# 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
版主选项: 回复 编辑
# 42630
Eypsn
To: eygle
　　 　大师:
请教一个问题:
带group by 的Select 语句, 在执行时间上Select 的影响大逭是group by的影响大.表很大,5000万记录以上, Select的结果(where条件均有索引)在5000条左右.

From: Eypsn
2007.01.16 19:51
To: Eypsn
　　什么意思?Group by要排序，当然会影响相应时间。Select你是指不加Group by ?
From: eygle
2007.01.17 15:35
版主选项: 回复 编辑
# 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
版主选项: 回复 编辑
# 42632
lone_zz
To: eygle
　　老大。我在读这本书。看你的网站中推荐读的。Expert Oracle Database
Architecture 9i and 10g Programming Techniques and Solutions。
在31页中有：

You’ll need to know three pieces of information before running the spcreate.sql script:
&#8226; The password you would like to use for the PERFSTAT schema that will be created
&#8226; The default tablespace you would like to use for PERFSTAT
&#8226; The temporary tablespace you would like to use for PERFSTAT

我在9i中操作，是先建立PERFSTAT tablespace永久表空间。
再执行spcreate.sql但我按照他说的把默认表空间和临时表空间都设置为PERFSTAT。报错。因为 永久表空间 不能为临时表空间。
这个是不是因为我在9i下的问题。10g上就没有这个问题了呢？
还是有什么解决方案。
我自己的解决方案是临时表空间用temp.默认表空间为PERFSTAT。
但好像违背了tom的本意哦。我该如何操作呢？

另外chapter00中的例子的用户好像很乱，一会9i。一会10g。都不知道在什么用户下操作了。
如关于31页的Custom Scripts部分，我应该在怎样的用户下操作呢？这个用户需要有什么权限。谢谢。老大。打扰了。

现在正在读oracle性能调优。你编的那本。感觉不错。


From: lone_zz
2007.01.15 15:30
To: lone_zz
　　他这里说的PERFSTAT 是指"PERFSTAT"用户，不是表空间啊!
这个用户应该指定一个临时表空间。
From: eygle
2007.01.17 17:17
版主选项: 回复 编辑
# 42626
Dusty


来自: 四川

To: eygle
　　最近做大对象的读写，在写更新NCLOB时遇到一些问题，想请教一下。PC程序如下：
bool UpdateNclobCol( const char* owner_name, //所有者名
const char* table_name, //表名
const char* where_stmt, //where条件
const char* column_name, //NCLOB字段列名
const char* file_path) //外部文件名
{
EXEC SQL BEGIN DECLARE SECTION;
OCIClobLocator character set is nchar_cs *nclob ;
unsigned int amt, offset = 1 ;
unsigned filelen=0, remainder,nbytes;
#define MAXBUFLEN 5000
char character set is nchar_cs buffer1[MAXBUFLEN+1];
char stmt[2000]="";
EXEC SQL END DECLARE SECTION;
........
EXEC SQL COMMIT;
return true;
}
在9i下运行正常，但是在8i下提示：ＬＯＢ类型不匹配错误．
是不是８i下不能这样定义ＮＣＬＯＢ：OCIClobLocator character set is nchar_cs *nclob ;那又该是怎么定义，或者说8i跟9i字符集有什么不一样，急，望赐教。

From: Dusty
2007.01.15 11:10
版主选项: 回复 编辑
# 42625
桂林


来自: bj

To:
　　请教：
select JT_W_TJD_1_seq.nextval from dual
这样的ｓｑｌ语句也会在ｏｐｅｎ＿ｃｕｒｓｏｒｓ中存在，怎样清除？
多谢！！

From: 桂林
2007.01.14 22:21
To: 桂林
　　使用的时候，游标自然要Open，Oracle会根据自己的算法管理游标，按照内部算法进行老化清除，你无需关心的，如果游标数不够，可以把open_cursors设大一点。
From: eygle
2007.01.15 20:48
版主选项: 回复 编辑
# 42623
chi


来自: MX

To: Eygle
　　My RMAN backup on the new AIX 5.3L is VERY VERY slow, almost hang. The backup script:
backup as compressed backupset incremental level 0 cumulative device type disk tag 'bkup$LEVEL_0' database;

$ rman target / nocatalog
Recovery Manager: Release 10.2.0.1.0 - Production

RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/dbrecovery/flash_recovery_area/%U';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracleapp/oracle/product/10.2.0/db_1/dbs/snapcf_baanbk.f'; # default

The same script run well and fast on RHEL3, which only has 1 CPU.
What went run?
From: chi
2007.01.12 07:29
To: chi
　　我想了解的时，慢的时候系统在等待什么?数据库在等待什么?wait event 是哪些?
From: eygle
2007.01.15 20:44
版主选项: 回复 编辑
页: 1 - << < 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 > >> - 310
我要留言
Copyright © 2003-2008 eygle.com All Rights Reserved.
Powered by: www.eYgLe.com