eygle.com   eygle.com
eygle.com  
 
留言簿 - Powered by eYgLe.Com
eygle.com 我要留言
如何进一步提高Oracle技术水平
昵称
内容 页: 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 > >> - 309
# 42894
ghb
To:
　　set termspool off 问题
oracle 9.2.0.4


在sqlplus 中使用spool user.txt 将查询到的结果保存到user.txt中，但不想将结果输出到屏幕。

sqlplus>set termspool off
SP2-0158: unknown SET option "termspool"
报错


sqlplus>set termout off
还是会将结果输出到屏幕。



有知道的朋友说一下吧，谢谢..


From: ghb
2007.05.30 16:05
To: ghb
　　
refer:
http://www.eygle.com/archives/2005/04/eoasqlplusieaae.html

From: eygle
2007.05.30 17:25
版主选项: 回复 编辑
# 42893
Chi


来自: Mexico

To: Eygle
　　This is the following of my previous post about the frequent redo log switching. My current redo log size is 50 MB each.You noticed that those switchings only occurred in the early morning around 8 am when users report to work.After that hour, the switching is back to normal, every 2 hours.I am pretty sure that our user just log into BAAN system ( which is linked to Oracle), not run any process on Oracle yet.That puzzled me, what caused the oracle to run so many redo log switchings, while during the real business hour (9 am ~ 5 pm), it does not.Some user (in oracle forum) said that as long as there is no "CHECKPOINT NOT COMPLETE" in alert log, I should not worry; or to increase the FAST_START_MTTR_TARGET.
From: Chi
2007.05.29 23:26
To: Chi
　　
1.对于大量的日志，可以通过LOGMNR去分析一下
2.对于频繁的log switch
是否需要调整，那要酌情而定
FAST_START_MTTR_TARGET 仅是一个Target，你不能指望这个参数在系统繁忙或异常时还能给你保证
再者，LOG SWITCH本身就是有消耗的，在LOG Switch阶段，LOG Generate是完全禁止的，而且频繁的switch不可避免的引发IO竞争

这只是一个判断问题。

From: eygle
2007.05.30 16:14
版主选项: 回复 编辑
# 42892
NinGoo
To:
　　eygle,给我加个链接吧
From: NinGoo
2007.05.29 20:08
To: NinGoo
　　好的，没有问题!加到首页去!
From: eygle
2007.05.30 15:38
版主选项: 回复 编辑
# 42891
wzknet


来自: 广州

To:
　　（三）请eygle老师有空帮忙看看，谢谢~
最近发现有前台连不上数据报障，经查系统不定时会在现有tnslsnr进程下产生一个lnslsnr子进程，如下
local1:/ #ps -ef | grep tnslsnr
oracle 925826 1 0 Apr 06 - 234:50 /u01/app/oracle/product/102/bin/tnslsnr listener1 -inherit
oracle 1081540 925826 0 21:39:39 - 0:00 /u01/app/oracle/product/102/bin/tnslsnr listener1 -inherit
把lnslsnr子进程kill掉后恢复正常。
From: wzknet
2007.05.29 15:38
To: wzknet
　　
很奇怪，你能不能检查一下监听日志看一下这个进程是如何启动的？
From: eygle
2007.05.30 16:15
版主选项: 回复 编辑
# 42890
wzknet


来自: 广州

To:
　　（二）请eygle老师有空帮忙看看，谢谢~
Security ON: Local OS Authentication
SNMP ON
Listener Parameter File /u01/app/oracle/product/102/network/admin/listener.ora
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=local1_boot1)(PORT=1521)))
Services Summary...
Service "db1.world" has 2 instance(s).
Instance "db1", status UNKNOWN, has 1 handler(s) for this service...
Instance "db1", status READY, has 1 handler(s) for this service...
Service "db1XDB.world" has 1 instance(s).
Instance "db1", status READY, has 1 handler(s) for this service...
Service "db1_XPT.world" has 1 instance(s).
Instance "db1", status READY, has 1 handler(s) for this service...
The command completed successfully
故障现象如下：
正常时系统只有一个tnslsnr进程：
local1:/home/oracle #ps -ef | grep tnslsnr
oracle 925826 1 0 Apr 06 - 338:59 /u01/app/oracle/product/102/bin/tnslsnr listener1 -inherit

From: wzknet
2007.05.29 15:36
版主选项: 回复 编辑
# 42889
wzknet


来自: 广州

To: eygle老师
　　（一）请eygle老师有空帮忙看看，谢谢
主机：IBM P570
平台：AIX 5.2
Oracle版本信息如下：
SQL> select * from V$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.1.0 - Productio
NLSRTL Version 10.2.0.1.0 - Production

监听状态信息如下：
local1:/home/oracle #lsnrctl status

LSNRCTL for IBM/AIX RISC System/6000: Version 10.2.0.1.0 - Production on 28-MAY-2007 18:21:58

Copyright (c) 1991, 2005, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias listener1
Version TNSLSNR for IBM/AIX RISC System/6000: Version 10.2.0.1.0 - Production
Start Date 06-APR-2007 07:03:04
Uptime 52 days 11 hr. 18 min. 54 sec
Trace Level off
接下一个留言。
From: wzknet
2007.05.29 15:34
版主选项: 回复 编辑
# 42888
kcfly


来自: hangzhou

To:
　　eygle，您好，请您有空帮我看看这个错误！
ora-00600错误
Errors in file /u01/app/oracle/admin/oradb/udump/oradb_ora_30110.trc:
ORA-00600: internal error code, arguments: [kkqtfixfro:2], [], [], [], [], [], [], []
我查了有关ora-00600的错误很多资料发现没有arguments: [kkqtfixfro:2]的处理方法，现在可以肯定的是只要有大的sql语句（比较复杂的那种就会出现这样的错误）
我的数据库是10.2.0的
From: kcfly
2007.05.29 14:40
版主选项: 回复 编辑
# 42887
lvlisong
To: eygle
　　eygle大哥,你好,我现在服务器有这个错误,偶尔发生.
网上也找不到好的答案,请帮忙分析,谢谢!
Mon May 28 16:56:54 2007
Errors in file /data1/ora9/admin/metdb01/udump/metdb01_ora_28666.trc:
ORA-07445: exception encountered: core dump [opiodr()+966] [SIGSEGV] [Address not mapped to object] [0xC] [] []
Mon May 28 21:49:01 2007
Thread 1 advanced to log sequence 51570
  Current log# 3 seq# 51570 mem# 0: /data1/ora9/oradata/metdb01/redo03.log
From: lvlisong
2007.05.29 09:21
版主选项: 回复 编辑
# 42886
小小草


来自: 南京

To:
　　To:
　　primary的日志归档后，怎样自动删除主机和备机上已经apply的日志文件，将未apply的日志文件保留？
From: 小小草
2007.05.09 17:59
 
  To: 小小草
　　删除应该和你的备份机制相结合，或者可以通过自己写脚本来处理。
From: eygle
2007.05.10 15:43

大师，能否详细指点一二呢?谢谢了！深入浅出里没有讲有关内容。
  From: 小小草
2007.05.21 14:23
 
 To: 小小草　　
你可以定义一个时间间隔，主节点比如通过RMAN备份，延迟一天删除
从库可以根据警告日志中的记录来删除应用过的日志。

先谢谢您了，主节点延迟一天删除也是有问题的，比如：主备间的网络断了，没发现，如果删除了主节点的归档，那备用的还没接收呀
 

From: 小小草
2007.05.29 08:49
To: 小小草
　　
那你这么说，主节点延迟1年删除也有问题，你总得有人维护阿；
或者，你可以根据备用节点的应用日志来删除主节点日志，这也是可以的
From: eygle
2007.05.29 08:58
版主选项: 回复 编辑
# 42885
Ch


来自: Mexico

To: Eygle
　　In your article: oracle_hotbackup_redo.html, You mentioned that "如果数据库块大小等于操作系统块大小，则可以设置该参数 ( _log_blocks_during_backup ) 为False，减少热备期间数据库的负担.What do you mean "数据库块大小等于操作系统块大小"? Does the DB needs to restart after alter this parameter?
From: Ch
2007.05.29 05:48
To: Ch
　　
这只是说明该参数和系统的关系；实际上"数据库块大小等于操作系统块大小"基本上是不存在的，所以也不必考虑。

这句话的意思是说，如果""数据库块大小等于操作系统块大小"，那么就不会有分裂块的出现，也就不必设置log_blocks_during_backup

From: eygle
2007.05.29 09:01
版主选项: 回复 编辑
页: 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 > >> - 309
我要留言
Copyright © 2003-2008 eygle.com All Rights Reserved.
Powered by: www.eYgLe.com