|
# 42798
Chi
来自: Mexico
|
|
|
To: Eygle
Don't worry about my problem to get your statspack pdf file.After download the simplified chinese font for the Adobe, I can read it now.
If you can ask Julia to write some summary of each your article or the subject of your article / papers in English, I am sure that more people outside China will recognize your work.As Stanford professor Paul Romer claims that it is knowledge economy world now. THe knowledge recognition will dominate the world.
From: Chi 2007.04.15 04:45
|
|
|
|
|
To: Chi
一直有用英文写的打算,不过还是决心不够,先在中文的世界里混着吧。
From: eygle 2007.04.16 10:36
|
|
|
|
|
# 42796
Chi
来自: Mexico
|
|
|
To: Eygle
I can not get your Statspack使用指南-V3.0(pdf版本) at http://www.eygle.com/pdf/Statspack-v3.0.pdf.My pdf opens it with lots ".." except the English part. I can use my pdf to read other chinese version pdf file.
From: Chi 2007.04.14 06:39
|
|
|
|
|
# 42794
Julia
|
|
|
To: Eygle
Here comes the weekend!!!Hia hia hia hia hia.....
From: Julia 2007.04.13 17:31
|
|
|
|
|
# 42793
Chi
来自: Mexico
|
|
|
To: Eygle
For exampel here are my. which is the most critical process in Oracle:
ps -ef | grep "oracle "
oracle139364 1 0 Feb 04- 29:24 ora_mmon_BAAN
oracle438508 1 0 Feb 04-6:55 /u020/apps/oracle/10.2
dbconsole /u020/apps/oracle/10.2.0/baanserver_BAAN/sysman/log/emdb.nohu
oracle471276 1 0 Feb 04- 62:37 ora_mmnl_BAAN
oracle565354438508 0 Feb 04- 76:48 /u020/apps/oracle/10.2
oracle569414 1 0 Feb 04- 12:05 ora_pmon_BAAN
oracle622664655390 1 13:35:01pts/20:00 ps -ef
oracle655390 1343614 0 13:31:40pts/20:00 -ksh
oracle663668 1 0 Mar 22-1:53 /u020/apps/oracle/10.2
oracle671932 1 0 11:02:05-0:03 oracleBAAN (LOCAL=NO)
oracle901230655390 0 13:35:01pts/20:00 grep oracle
pps/oracle/10.2.0 -Doracle.home=/u020/apps/oracle/10.2.0/oc4j -Doracle.
oracle 1544220 1 0 Apr 10-0:49 oracleBAAN (LOCAL=NO
From: Chi 2007.04.13 02:46
|
|
|
|
|
To: Chi
ps -ef|grep ora_
主要看后台进程,用户进程一般无需调整优先级的。
From: eygle 2007.04.13 16:56
|
|
|
|
|
# 42792
clovey
来自: 杭州
|
|
|
To: eygle
你好,在你这里学习了很久了,也学习了很多东西,最近遇到些问题想请教一下,
我的站点现在访问越来越大,但数据库服务器占CPU不是很高,30-40%,有4个G的内存,缓冲池设置了1.9个G,对了,服务器是双CPU,是不是并发处理不够呀,服务器老是卡,在流量大时数据处理就会有问题,站点反应也慢,像这样的怎么解决?要靠硬件来解决吗?有没有服务器配置的标准参考一下呀,谢谢了
From: clovey 2007.04.12 17:39
|
|
|
|
|
To: clovey
这个不好猜,原因可能是多方面的,具体诊断一下才能知道。
From: eygle 2007.04.13 16:55
|
|
|
|
|
# 42791
qi
|
|
|
To: eygle
谢谢eygle,问题已解决,增加了参数:_allow_resetlogs_corruption=true
然后recover database using backup controlfile until cancel;
alter database open resetlogs;
数据库终于启动成功!
不过原理不很明白 ,呵呵。
From: qi 2007.04.12 14:51
|
|
|
|
|
To: qi
强制数据库跳过一系列的一致性检查,这些参数我的网站上就有文章介绍。
现在越来越懒得提这些隐含参数了,要学习怎样使数据库免于面临这样的境地。
From: eygle 2007.04.12 15:53
|
|
|
|
|
# 42790
qi
|
|
|
To: eygle
你resetlogs过了,日志被你清空了。
那再怎么办?开机开不了了?开机就是数据文件需要恢复。
From: qi 2007.04.12 08:02
|
|
|
|
|
# 42788
qi
|
|
|
To: eygle
其实我之前做了每一个redo文件都试过了,不行.
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 396933 (在 04/04/2007 15:07:28 生成) 对于线程 1 是必需的
ORA-00289: 建议: E:\ARCHIVE\ARC0012.ARC
ORA-00280: 更改 396933 对于线程 1 是按序列 # 2 进行的
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
F:\ORACLE\ORADATA\DWYC\REDO03.LOG
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'F:\ORACLE\ORADATA\DWYC\REDO03.LOG'
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件1需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\ORACLE\ORADATA\DWYC\SYSTEM01.DBF'
查询redo文件如下:SQL> select * from v$log;
GROUP#THREAD#SEQUENCE#BYTESMEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- -------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1101048576001 YES UNUSED
0
2101048576001 YES UNUSED
0
3101048576001 YES INVALIDATED
0
查询数据文件的SCN为:396933
From: qi 2007.04.11 16:01
|
|
|
|
|
To: qi
你resetlogs过了,日志被你清空了。
From: eygle 2007.04.11 16:24
|
|
|
|
|