一个没有索引引起的问题

这个案例说来也很简单。话说我们公司旧版本的mediation系统每天都需要从各个network elementNE)的服务器上采集CDR,采集程序一般都是用expect写的,其实就是ftp到对方的机器上拷贝文件过来。NE里的CDR一般不会轻易做house keep,这就要求我们的采集程序自己能够辨认哪些文件已经下载过,否则的话,全部下载过来处理,客户就要被重复计费了。因此,在本地数据库中,有一个表专门保存已经下载过的文件名字,采集程序ftp登录之后,首先会使用ls命令看看目标路径里都有些什么文件,然后逐一以这些文件名为查询条件,到本地数据库的表中查一下,有没有这个文件的下载记录,如果有,再查下一个文件名,如果没有,把这个文件名保存到缓冲区,全部查询完成之后,再根据缓冲区中的文件列表逐一下载该文件,下载一个就往数据表插入一条该文件的下载记录。

 

看上去天衣无缝吧。谁知道某一天,问题来了。大家知道,ftp是有超时设置的,而采集程序ftp登录之后,逐一查找比较文件有没有曾经下载过,也是需要时间的,如果文件数量比较多,查找时间大于ftp的超时设置,这样下载就永远不会成功了。每次经过千辛万苦的查找之后,都会弹出令人沮丧的消息:

 

[25.05 10:34:05] Step 001 LOG      SQL> ftp> bin
[25.05 10:34:05] Step 001 LOG      Not connected.
[25.05 10:34:05] Step 001 INFO     FTP_CLIENT mo_bg-CDR_2010-05-25T000932.log.gz start copying
[25.05 10:34:05] Step 001 LOG      get CDR_2010-05-25T000932.log.gz /usr/users/nmds/amd/arm/input/raw/mo_bg1/tmp-mo_bg-CDR_2010-05-25T000932.log.gz-tmp
[25.05 10:34:05] Step 001 LOG      Not connected.

 

还好日志上有时间戳,记录了采集程序从登录成功到真正开始传输,足足等待了超过5分钟,说明当中的查找比较过程太慢了。翻看源程序,发现执行的SQL是:

 

SELECT SYSID from smt_ftp_files where SYSID ='$SYSID' and FILENAME = '$FILENAME';

 

不必多说,这个查询应该在filename或者sysid字段上有索引,才会快。进入oracle数据库,看看其索引,竟然没有,于是新建一条,重新运行,读取要下载的文件列表只要十几秒,不到2分钟,整个下载过程都完成了。

 

SQL> select index_name from all_indexes where table_name='SMT_FTP_FILES';

 

no rows selected

 

SQL> create index idx_filename on smt_ftp_files(filename);

 

Index created.

 

SQL> select index_name from all_indexes where table_name='SMT_FTP_FILES';

 

INDEX_NAME
------------------------------
IDX_FILENAME

 

你可能感兴趣的:(oracle,sql,数据库,table,NetWork,2010)