在Oracle数据库实现自动断开后再连接
在实际的数据库应用中，我们经常遇到这样一个问题，连接到Oracle数据库的用户在作了一次操作后，再也没有后续操作，但却长时间没有和数据库断开连接。对于一个小型的应用系统来讲，本身的连接数目就有限，这好像没有什么严重的后果，但如果对于一个大型的数据库应用。如税务、工商等，如果数据库的连接数目很多，对于数据库服务器来讲，多一个连接就要多消耗一份资源，如果大量用户连接进入数据库系统但却不进行任何的操作，这无形之中就白白造成了服务器系统资源的浪费，同时造成服务器负载的提高，对于那些确实在工作的用户来讲，就不能最大限度的利用服务器的资源，严重情况下可能造成系统性能的急剧下降。
针对这种问题，该如何处理呢？对于目前流行的三层结构（Browser/Application/Server）开发来讲，这个问题可以通过设置应用服务器端的连接共享池（shared pool）来避免。但对于传统的两层结构（Client/Server）应用，就必须由我们人为干预来避免这种资源浪费情况。具体可以通过一个后台任务来监控系统中的所有进程，对于那些空闲超过一定时间的进程采取一定的特殊处理措施，如在客户端提示用户连接时间太长，如果没有后续操作系统将自动杀掉该连接或者直接将该空闲连接杀掉。下面就来具体讨论如何在Oracle 8x环境下实现用户进程的自动监控及其对对超过一定空闲时间连接的处理办法。
一、识别系统中超过一定空闲时间的连接
要实现后台任务自动对超过一定时间空闲连接的处理，首先第一步工作就是要从所有与数据库服务器的连接中识别出那些连接需要处理，也就是需要获得与服务器连接的每个用户的登陆时间及其最后一次操作后的空闲时间。在Oracle系统中，有一个动态性能视图v$session，该视图保存着系统当前连接的各种动态信息。其中，有两个字段LOGON_TIME和 LAST_CALL_ET可以得到上面的两个答案。
LOGON_TIME是一个日期型（Date）字段，为用户登陆时间；
LAST_CALL_ET是一个数字型（Number）字段，其含义是用户最后一条语句执行完毕后的时间，单位为秒。每次用户执行一个新的语句后，该字段复位为0，重新开始记数。我们可以通过该字段来获得一个连接用户最后一次操作数据库后的空闲时间。
下面的SQL查询语句可以得到与当前数据库连接的所有用户的一些基本情况，如用户名、状态、连接机器的名称，操作系统中用户的名称，UNIX系统的进程号，在UNIX操作系统级断开连接的语句，Oracle数据库系统断开连接的语句，登陆时间以及最后一次操作到现�
相关文档：
方法一：offline表空间
1、offline表空间：alter tablespace tablespace_name offline；
2、复制数据文件到新的目录；
3、rename修改表空间，并修改控制文件；
4、online表空间；
1、offline表空间zerone
SQL> select name from v$datafile;
NAME
--------------------------------------------------------- ......
--删除空的表空间，但是不包含物理文件
drop tablespace tablespace_name;
--删除非空表空间，但是不包含物理文件
drop tablespace tablespace_name including contents;
--删除空表空间，包含物理文件
drop tablespace tablespace_name including datafiles;
--删除非空表空间，包含物理文件
drop tablespace table ......
我们知道,在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:
alter system kill session 'sid,serial#' ;
被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.
我们发现当一个session被kill掉以后，该session的paddr被修改，如果有多个session被kil ......
oracle通过透明网关（Oracle Transparent Geteways），访问ms sql server和其他数据库
环境：
1、在安装有oracle服务器端，ms sql server的客户端，通过oracle的透明网关访问ms sql server数据库
2、在ms sql ser ......
Oracle Flashback Technology
Oracle Flashback Technology reduces recovery time from hours to minutes.
from: http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm
According to many studies, 40% of application outages are caused by operator or user errors. Part of be ......
