eygle.com   eygle.com
eygle.com  
 
留言簿 - Oracle Life - Powered by Eygle.com
eygle.com 我要留言
《 深入浅出Oracle》内容简介
昵称
内容 页: 1 - << < 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 > >> - 404
# 1118
新手
To: eygle
　　偶是哪个啊？
From: 新手
2005.07.09 20:05
To: 新手
　　[COLOR=blue]？[/COLOR]
From: eygle
2005.07.10 01:12
版主选项: 回复 编辑
# 1117
John
To: eygle
　　exec dbms_system.set_sql_trace_in_session
做的报告怎么没有执行计划呢？

SQL> alter session set sql_trace=true ;
会话已更改。
SQL> exec dbms_system.set_sql_trace_in_session(9,37,true);
PL/SQL 过程已成功完成。
SQL> exec dbms_system.set_sql_trace_in_session(9,37,false)
PL/SQL 过程已成功完成。
SQL>

tkprof 'D:\Oracle\admin\oradb\udump\oradb_ora_1040.TRC' 'd:\aaaag.txt'

报告如下：

TKPROF: Release 9.2.0.1.0 - Production on 星期六 7月 9 22:45:50 2005

Copyright (c) 1982, 2002, Oracle Corporation.All rights reserved.

Trace file: D:\Oracle\admin\oradb\udump\oradb_ora_1040.TRC
Sort options: default

********************************************************************************
count= number of times OCI procedure was executed
cpu= cpu time in seconds executing
elapsed= elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query= number of buffers gotten for consistent read
current= number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
********************************************************************************

select *
from
 t_mz_sf


call count cpuelapsed diskquerycurrentrows
------- -------------- ---------- ---------- ---------- --------------------
Parse10.00 0.00000 0
Execute10.00 0.00000 0
Fetch10.00 0.00030 0
------- -------------- ---------- ---------- ---------- --------------------
total30.00 0.00030 0

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 62



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call count cpuelapsed diskquerycurrentrows
------- -------------- ---------- ---------- ---------- --------------------
Parse10.00 0.00000 0
Execute10.00 0.00000 0
Fetch10.00 0.00030 0
------- -------------- ---------- ---------- ---------- --------------------
total30.00 0.00030 0

Misses in library cache during parse: 0


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpuelapsed diskquerycurrentrows
------- -------------- ---------- ---------- ---------- --------------------
Parse00.00 0.00000 0
Execute00.00 0.00000 0
Fetch00.00 0.00000 0
------- -------------- ---------- ---------- ---------- --------------------
total00.00 0.00000 0

Misses in library cache during parse: 0

  1userSQL statements in session.
  0internal SQL statements in session.
  1SQL statements in session.
********************************************************************************
Trace file: D:\Oracle\admin\oradb\udump\oradb_ora_1040.TRC
Trace file compatibility: 9.00.01
Sort options: default

 0session in tracefile.
 1userSQL statements in trace file.
 0internal SQL statements in trace file.
 1SQL statements in trace file.
 1unique SQL statements in trace file.
 8lines in trace file.



From: John
2005.07.09 07:56
To: John
　　[COLOR=blue]你直接看一下trace文件，先不要格式化[/COLOR]
From: eygle
2005.07.10 01:12
版主选项: 回复 编辑
# 1115
kenny
To: Eygle
　　Eygle,我看了关于benchmark压力测试的文章，orabm这些工具都是for unix的，如果oracle运行在win下，有什么压力测试工具呢？
From: kenny
2005.07.08 19:42
To: kenny
　　[COLOR=blue]我宁愿用Linux也不会选择Windows的，windows上的工具也很多，比如quest benchmark factory等，你可以Google一下[/COLOR]
From: eygle
2005.07.10 01:11
版主选项: 回复 编辑
# 1114
Sabrina
To: eygle
　　在office听歌.
刘若英的<一辈子的孤单>,推荐你听.

From: Sabrina
2005.07.08 06:01
To: Sabrina
　　[COLOR=blue]天下无贼里的，我知道[/COLOR]
From: eygle
2005.07.08 06:26
版主选项: 回复 编辑
# 1112
新手
To: eygel
　　网站浏览量很大，技术和生活的论坛，你会成功的！！！远离尘嚣！！！
From: 新手
2005.07.08 01:52
To: 新手
　　[COLOR=blue]谢谢支持，欢迎常来。[/COLOR]
From: eygle
2005.07.08 02:21
版主选项: 回复 编辑
# 1110
jianw3400
To:
　　你认为Veritas备份oracle好用吗？有没有rman好用吗
From: jianw3400
2005.07.07 23:54
To: jianw3400
　　[COLOR=blue]如果你说的是Veritas的NBU，那也是要用到RMAN的；如果你说的是Veritas的Snapshot等功能，那又是另一回事；建议看看文档先。[/COLOR]
From: eygle
2005.07.08 00:04
版主选项: 回复 编辑
# 1108
jianw3400
To:
　　你用过Veritas备份oracle吗？如果使用过，你能介绍一下？谢谢
From: jianw3400
2005.07.07 17:48
To: jianw3400
　　[COLOR=blue]题目太大了吧，你看一下NBU的手册就差不多了[/COLOR]
From: eygle
2005.07.07 19:22
版主选项: 回复 编辑
# 1107
Sabrina
To: eygle
　　最近好吗？
今天在网上乱晃，翻出去年我们的PM，感触良多。
希望以后一切都好。
From: Sabrina
2005.07.07 09:59
To: Sabrina
　　[COLOR=blue]惟有年华老去，是不是呢?[/COLOR]
From: eygle
2005.07.07 19:23
版主选项: 回复 编辑
# 1106
fly


来自: bj

To:
　　eygle老大请教一个问题，上次听你的课好象说到往一个表中插入大数量级，中途终止进程的一个案例，如：
insert into a select * from b where XXXX
大概数量级在1000万以上

我今天的问题跟这个一样，我昨天晚上从一个表往另一个表导数据，大概有1000多万，导了12个小时后，还没有反应，不得以只有终止进程，可是进程终止后，发现系统的IO很高，通过检查发现是SMON进程一直在执行如下语句：
/* Formatted on 2005/07/07 22:11 (Formatter Plus v4.8.0) */
SELECT o.owner#, o.NAME, o.namespace, o.remoteowner, o.linkname, o.subname,
 o.dataobj#, o.flags
  FROM obj$ o
 WHERE o.obj# = :1

通过v$session_wait视图，发现SMON进程一直在发生db file sequential read的等待事件。现在已经持续1天了。
不知道上次你的那个案例最后怎么样？？是怎么解决的，可以相告吗？先谢谢那

我的MAIL：crpp0902@itpub.net
From: fly
2005.07.07 06:39
To: fly
　　[COLOR=royalblue]事务要回滚啊，你查一下V$TRANSACTION视图，检查USED_UBLK和USED_UREC，观察其变化就能估计出来回滚需要的时间，下次应该批量插入提交，不要一次操作这么大量的数据。[/COLOR]
From: eygle
2005.07.07 06:44
版主选项: 回复 编辑
# 1105
雁渡寒潭
To:
　　现在出现了日志切换过快的问题。
和db_writer_processes无关吧.我查看了资料，说这个问题是由于并行回滚引起的。

这是怎么发生的，如何导致了日志切换，还是在日志切换的时候导致的回滚。你能给我解释一下吗？
From: 雁渡寒潭
2005.07.07 00:53
To: 雁渡寒潭
　　[COLOR=blue]日志切换快是redo生成的多，怎么又扯上了db_writer了呢?[/COLOR]
From: eygle
2005.07.07 06:46
版主选项: 回复 编辑
页: 1 - << < 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 > >> - 404
我要留言
Copyright © 2003~2012 eygle.com All Rights Reserved.
Powered by: www.eygle.com