Content Preview: rss
1228 days ago
V$SQL Child cursor details for V$SQLAREA V$SQLAREA Shared pool details for statements/anonymous blocks V$SQLTEXT SQL text of statements in the shared pool 都是通过 ADDRESS 和 HASH_VALUE 可以为一判定一个 SQL 在两个不同的用户里分别建立 wwm 表，用两个用户分别运行 select * from wwm. 则在 v$sql 里是两条记录（两个 cursor ）， ADDRESS 和 HASH_VALUE 却是相同的。但在 v$sqlarea,v$sqltext 却只有一条记录。 V$sqlarea 是 v$sql 合并 cursor 后的结果 . 可以通过 v$sql 的 PLAN_HASH_VALUE 来判断两个 SQL 的执行计划是否相同。 V$sqltext 能查到 SQL 语句的全部（将一个 SQL 分为多条记录，每条记录 64 字节，通过 HASH VALUE 来判断是否属于一条 SQL ），但 v$sql, v$sqlarea 只显示 1000 字节。所以要访问 V$SQLTEXT 最好根据 piece 去排序，来组织正确的 SQL 。 用 A 用户执行 SELECT * FROM WWM ORDER BY ID 1 次，用 B 用户执行 SELECT * FROM WWM ORDER BY ID 3 次，则 select sql_text,sorts from v$sql where sql_text like '%wwm%' SQL_TEXT ...
1228 days ago
SQL> create table wwm( thechar char(10),thevarchar varchar2(20),thenumber number(10,2)); Table created. SQL> select * from wwm; THECHAR THEVARCHAR THENUMBER ---------- -------------------- ---------- dsffg varchar2 10.2 wwm wwmwwm2 -999.2 charcharch charcharcharcharchar 100000000 1 * select thechar,dump(thechar) from wwm SQL> / THECHAR DUMP(THECHAR) ----------------------------------------------------------- Dsffg Typ=96 Len=10: 100,115,102,102,103,32,32,32,32,32 Wwm Typ=96 Len=10: 119,119,109,32,32,32,32,32,32,32 Charcharch ...
1228 days ago
问题是在建立LOB字段时发生的，用 dmsdeuser1用户执行 SQL> connect dmsdeuser1/pass@sid SQL> CREATE TABLE CONTENT ( 2 MSG_ID CHAR(100) NOT NULL, 3 MSG_DATA BLOB, 4 CONSTRAINT PK_CONTENT PRIMARY KEY (MSG_ID) 5 ); CREATE TABLE CONTENT ( ERROR at line 1: ORA-03237: Initial Extent of specified size cannot be allocated in tablespace (DATA01) dmsdeuser1用户默认表空间是DATA01，是UNLIMITED 首先看表空间是否有空余空间 SQL> SELECT A.TABLESPACE_NAME,A.BYTES TOTAL,B.BYTES USED, C.BYTES FREE, (B.BYTES*100)/A.BYTES "% USED",(C.BYTES*100)/A.BYTES "% FREE" FROM SYS.SM$TS_AVAIL A,SYS.SM$TS_USED B,SYS.SM$TS_FREE C WHERE A.TABLESPACE_NAME=B.TABLESPACE_NAME AND A.TABLESPACE_NAME=C.TABLESPACE_NAME; TABLESPACE_NAME ...
1228 days ago
发现ＣＰＵ占用率一般都维持在９０％以上，由于大量使用ＦＯＲ ＵＰＤＡＴＥ，造成大量ＬＡＴＣＨ等等待现象，其中某些多线程ＳＱＬ又运行非常频繁。很久以前就发现这些问题，给出相对意见，建议不采用ＦＯＲ ＵＰＤＡＴＥ或在ＦＯＲ ＵＰＤＡＴＥ上加ＮＯＷＡＩＴ（见 http://spaces.msn.com/sunmoonking/blog/cns!E3BD9CBED01777CA!318.entry “ELECT FOR UPDATE 相关的知识”一章 ），由于项目进程问题一直没进行程序修改，决定在这次解决掉，以解后顾之忧。 调整前要知道如下问题 1，CPU是多少MHZ 2，SERVER 端的CPU是否有负荷较重 3，CLIENT 端的CPU是否有负荷较重 4，空闲时间（如半夜）CPU使用率是否超过15%，如果超过则需要特别注意了 5，CPU的PEAK LOAD 6，CPU的IDLE STATE 影响ＣＰＵ的因素 1，高的无必要的解析会代价昂贵。 发现那些SQL运行了大量的PARSE select sql_text, parse_calls, executions from v$sqlarea order by parse_calls desc; SYS的总的PARSE情况 select name, value from v$sysstat where name = ’parse count%’; 只有硬解析才能减少，可以绑定变量，或增加每一个SESSION的CACHED CURSORS。 2，导致大量I/O的SQL也会明显占用CPU，如没有INDEX。BUFFER GETS一般会同CPU一块增长。可以通过v$sqlarea发现buffer_gets 3，其他等待时间，可以通过v$sesstat,v$sysstat查看 #VMSTAT 5 5 的CPU部分 us user用掉的 sy system用掉的 id 空闲 调整前 TOPAS Name PID CPU% PgSp Owner ...
1228 days ago
CREATE OR REPLACE procedure get_activity_code(in_activity_code in tm_recall_activity.activity_code%type, out_curEmp out SYS_REFCURSOR ) IS Col_c2 VARCHAR2(4000); Col_maxday number(5); the_day_count number(5); the_sql varchar2(4000); BEGIN the_day_count:='1'; --计数器 select max(floor(c.repair_date-e.startdate)) INTO Col_maxday --计算最大列数，因为列数是不固定的，比如此处是38 from tt_activity_vehicle c,tm_recall_activity e where e.recall_activity_id=c.recall_activity_id and e.activity_code='L001'; IF Col_maxday IS NULL THEN dbms_output.put_line('NO MAXDAY'); END IF; the_sql:='select b.rssc_name as rssc,d.labor_no as type '; while the_day_count<=Col_maxday LOOP --循环拼语句 the_sql:=the_sql ',decode(floor(c.repair_date-e.startdate),' the_day_count ',count(*),0)'; the_day_count:=the_day_count+1; --加一，要拼出满足需要的列来，比如循环38次 END LOOP; the_sql:=the_sql ...
