20060930:oracle常见系统表的使用

1．检查占用CPU时间比较长的sql语句:
select sql_text,cpu_time from v$sql where cpu_time >1e7 order by cpu_time

2．执行效率最差的10条sql语句
SELECT * FROM ( SELECT PARSING_USER_ID EXECUTIONS SORTS, COMMAND_TYPE, DISK_READS, sql_text FROM v$sqlarea ORDER BY disk_reads DESC) WHERE ROWNUM<10 ;

3.检查当前的数据库连接数
select * from v$session;

4.检查当前的数据库打开的游标数
select * from v$open_cursor;

20060930:cursor和apache的日志配置

1.关于游标和statement的测试
代码如下:
String sql_test= "insert into tt (A) values (?)";
Connection conn=this.getConnection();
PreparedStatement ps = null;
try{ for (int i=0;i<1000;i++)
{ ps = this.getSession().connection().prepareStatement(sql_test);
ps.setInt(1,i);
ps.execute();
conn.commit();
}
}
finally{ if (ps != null) ps.close(); }
数据库(oracle)设置的open_cursor=300
此时执行,只能插入tt表300条记录,然后报ora-01000,游标数超出的错.
为什么finally中明明有关闭statement,但还是会报错呢?
原因是这样的:
在应用程序中,有一个Preparement对象ps,每次循环在执行ps = this.getSession().connection().prepareStatement(sql_test); 的时候,都会在数据库端打开一个cursor,如果应用程序不通过ps.close()来关闭,则数据库会保持这个游标打开.因此,上面的那段代码,看似已经关闭了ps,但实际上只关闭了最后一次循环的那个游标,之前的都没有关闭.正确的代码应该是在循环里面,conn.commit();之后加上ps.close();

2.关于apache日志.
今天早上两台应用服务器的apache都down掉了,原因原来是mod_jk.log日志超过了2G.解决方法是在配置文件中将mod_jk的输出级别设置为error,然后再把日志删除,重启就可以了.

20060929:oracle和线程池

1.关于tomcat的SEVERE: All threads (150) are currently busy, waiting.
fms在下午两点左右,tomcat报这个.按说应该没有很多并发的用户,应该是系统有问题,而不是并发用户太多.查查是什么问题导致.


2.关于oracle的一些使用经验:摘自http://www.mikecat.net/blogview.asp?logID=1226
　ORACLE的数据字典是数据库的重要组成部分之一，它随着数据库的产生而产生, 随着数据库的变化而变化, 体现为sys用户下的一些表和视图。数据字典名称是大写的英文字符。
数据字典里存有用户信息、用户的权限信息、所有数据对象信息、表的约束条件、统计分析数据库的视图等。 我们不能手工修改数据字典里的信息。
　　很多时候，一般的ORACLE用户不知道如何有效地利用它。
　　dictionary　　　全部数据字典表的名称和解释，它有一个同义词dict dict_column　　 全部数据字典表里字段名称和解释
如果我们想查询跟索引有关的数据字典时，可以用下面这条SQL语句:
SQL>select * from dictionary where instr(comments,'index')>0;
如果我们想知道user_indexes表各字段名称的详细含义，可以用下面这条SQL语句:
SQL>select column_name,comments from dict_columns where table_name='USER_INDEXES';
依此类推，就可以轻松知道数据字典的详细名称和解释，不用查看ORACLE的其它文档资料了。
下面按类别列出一些ORACLE用户常用数据字典的查询使用方法。
1、用户
查看当前用户的缺省表空间 SQL>select username,default_tablespace from user_users;
查看当前用户的角色 SQL>select * from user_role_privs;
查看当前用户的系统权限和表级权限 SQL>select * from user_sys_privs; SQL>select * from user_tab_privs;
2、表
查看用户下所有的表 SQL>select * from user_tables;
查看名称包含log字符的表 SQL>select object_name,object_id from user_objects where instr(object_name,'LOG')>0;
查看某表的创建时间 SQL>select object_name,created from user_objects where object_name=upper('&table_name');
查看某表的大小 SQL>select sum(bytes)/(1024*1024) as "size(M)" from user_segments where segment_name=upper('&table_name');
查看放在ORACLE的内存区里的表 SQL>select table_name,cache from user_tables where instr(cache,'Y')>0;
3、索引
查看索引个数和类别 SQL>select index_name,index_type,table_name from user_indexes order by table_name;
查看索引被索引的字段 SQL>select * from user_ind_columns where index_name=upper('&index_name');
查看索引的大小 SQL>select sum(bytes)/(1024*1024) as "size(M)" from user_segments where segment_name=upper('&index_name');
4、序列号
查看序列号，last_number是当前值 SQL>select * from user_sequences;
5、视图
查看视图的名称 SQL>select view_name from user_views;
查看创建视图的select语句 SQL>set view_name,text_length from user_views; SQL>set long 2000; 说明：可以根据视图的text_length值设定set long 的大小 SQL>select text from user_views where view_name=upper('&view_name');
6、同义词
查看同义词的名称 SQL>select * from user_synonyms;
7、约束条件
查看某表的约束条件 SQL>select constraint_name, constraint_type,search_condition, r_constraint_name from user_constraints where table_name = upper('&table_name');
SQL>select c.constraint_name,c.constraint_type,cc.column_name from user_constraints c,user_cons_columns cc where c.owner = upper('&table_owner') and c.table_name = upper('&table_name') and c.owner = cc.owner and c.constraint_name = cc.constraint_name order by cc.position;
8、存储函数和过程
查看函数和过程的状态 SQL>select object_name,status from user_objects where object_type='FUNCTION'; SQL>select object_name,status from user_objects where object_type='PROCEDURE';
查看函数和过程的源代码 SQL>select text from all_source where owner=user and name=upper('&plsql_name');
三、查看数据库的SQL 1、查看表空间的名称及大小
select t.tablespace_name, round(sum(bytes/(1024*1024)),0) ts_size from dba_tablespaces t, dba_data_files d where t.tablespace_name = d.tablespace_name group by t.tablespace_name;
2、查看表空间物理文件的名称及大小
select tablespace_name, file_id, file_name, round(bytes/(1024*1024),0) total_space from dba_data_files order by tablespace_name;
3、查看回滚段名称及大小
select segment_name, tablespace_name, r.status, (initial_extent/1024) InitialExtent,(next_extent/1024) NextExtent, max_extents, v.curext CurExtent From dba_rollback_segs r, v$rollstat v Where r.segment_id = v.usn(+) order by segment_name ;
4、查看控制文件
select name from v$controlfile;
5、查看日志文件
select member from v$logfile;
6、查看表空间的使用情况
select sum(bytes)/(1024*1024) as free_space,tablespace_name from dba_free_space group by tablespace_name;
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;
7、查看数据库库对象
select owner, object_type, status, count(*) count# from all_objects group by owner, object_type, status;
8、查看数据库的版本
Select version FROM Product_component_version Where SUBSTR(PRODUCT,1,6)='Oracle';
9、查看数据库的创建日期和归档方式
Select Created, Log_Mode, Log_Mode From V$Database; 四、ORACLE用户连接的管理
用系统管理员，查看当前数据库有几个用户连接：
SQL> select username,sid,serial# from v$session;
如果要停某个连接用
SQL> alter system kill session 'sid,serial#';
如果这命令不行,找它UNIX的进程数
SQL> select pro.spid from v$session ses,v$process pro where ses.sid=21 and ses.paddr=pro.addr;
说明：21是某个连接的sid数
然后用 kill 命令杀此进程号

20060928:这两天的接口报错

从spider回tulip的接口,这两天主要有三个错误:

1.ora-01000.游标数超过了最大限制.oracle默认是300个.应用程序在使用connection.prepareStatement的时候,会打开数据库中的游标.如果没有正确关闭就会耗尽数据库的游标资源.但现在我在使用的地方都用在finally中关闭了resultSet和prepareStatement,还是报这个错.不知道应该怎么解决了.先把oracle的open cursor调大一些试试吧.

2.事务管理的问题.spider的某个单有三条明细,结果传到tulip中只有1条明细过来了.怎么会这样呢?虽然是跨数据库,但就算在只在tulip的部分,也不应该出现这种情况啊.下午好好看看

3.回tulip的收货单,在取单号的时候,居然取了一条已经使用过的单号.这个下午也要查查.

-----第1个问题已经查出来了,是代码里面没有正确关闭statement.查找此类错误的方法是:首先在oracle的v$open_cursor视图中查找占用游标最多的sql_text(或者hash_value).如果sql_text的长度不足够来判断,则通过v$open_cursor中的hash_value和v$sqlarea中的hash_value来关联查找完整的sql.
--第2个问题查出来了,是在dao里面用了try,catch,finally.catch把异常给抓住了,没有往上抛,所以spring在manager层管理的事务就捕获不到异常,也就不会回滚.导致部分明细保存了.解决方法就是把catch给去掉.但我还有个疑惑:我在catch里写了一个throw new RuntimeException,为什么manager还是捕捉不到异常呢?
--第3个问题查出来了,是因为tulip的出入库单是通过tulip接口中TulipConnection.java中用jdbc取的,其中url是写死在代码中.所以中间因为忽略了这个问题,有时候用的正式tulip的连接,有时候用的测试的tulip的连接,导致单号重复的问题.