Oracle回收站，ora 38301错误
ora-38301错误,回收站
前几天有同事告诉我，有台服务器上的表空间无法删除，让我看看。登录到服务器，删除表空间，数据库同时报ora-00604和ora-38301错误。起初以为是有数据库对象被锁定，重启数据库后，发现还是报同样的错误。Google后发现可能与10g的一个新特性回收站有关，清空回收站purge recyclebin后，进行删除还是报同样的错误。将表空间offline后进行删除也不行，想可能是还有什么关联对象没有被清空或依旧被占用。想起以前未删除表空间前删除用户时，提示是否删除关联的对象。先删除用户，选择删除用户时同时删除关联的级联对象，再删除表空间时，成功删除。同时也知道了oracle10g的一个新特性。
Oracle10g提供了类似操作系统中的回收站功能。回收站，从原理上来说就是一个数据字典表，放置用户Drop掉的数据库对象信息。当drop table的时候，实际上只是将其重命名，并将table以及相关联的对象如index，constraint等放到回收站(RecycleBin)中，后续如果发现drop错了table，可以使用flashback table命名将回收站中的table还原，这就是Oracle10g的Flashback Drop功能。
1. 启用/禁用RecycleBin：
通过设置初始化参数recyclebin，可以控制是否启用回收站功能，默认是开启的。
;`:v | } h;w2?)L r B0SQL> alter system set recyclebin=off;
系统已更改。
SQL> alter system set recyclebin=on;
系统已更改。
SQL> alter session set recyclebin=off;
会话已更改。
SQL> alter session set recyclebin=on;
会话已更改。
2. 查看回收站：
SQL> SHOW recyclebin;
或者
SQL>select * from recyclebin;
除非拥有sysdba权限，否则每个用户只能看到属于自己的对象。所以，对于用户来说，好像每个人都拥有自己的回收站。即使用户有删除其他schema对象的权限，也只能在recyclebin中看到属于自己的对象。
3. 回收站对象的操作：
当一个表被删除并移动到"回收站"中，它的名字要进行一些转换。这样的目的是为了避免同类对象名称的重复。(这一点和Windows操作系统的回收站不同，Windows中的回收站经过了特殊的处理，操作系统文件可以重名。)转换后的名字格式如下:
BIN$unique_id$version其中BIN代表RecycleBin，unique_id是数据库中该对象的唯一标志，26个字符长度vers
相关文档：
在J2EE应用程序开发中，应用程序与数据库连接的建立是我们经常遇到的问题之一。在这里我主要谈谈在本地应用程序中通过OCI方式、thin方式和JdbcOdbc桥方式连接Oracle数据库，在iPlanet Application Server 6.5和Sun Java System Application Server 7中对Oracle数据库连接池的配置以及应用中如何从连接池中获得连接
一、本� ......
转自： http://blog.csdn.net/kongqz/archive/2009/05/15/4184415.aspx
就是在已有的数据库实例上创建一个新的帐号，访问一些新的表
操作步骤如下：
1、登录linux，以oracle用户登录（如果是root用户登录的，登录后用 su - oracle命令切换成oracle用户）
2、以sysdba方式来打开sqlplus，命令如下： s ......
[资料来自于ORACLE频道 http://oracle.chinaitlab.com/induction/398193.html]
1. /*+ALL_ROWS*/
表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化.
例如:
SELECT /*+ALL_ROWS*/ EMP_NO,EMP_NAM,DAT_IN from BSEMPMS WHERE EMP_NO='SCOTT';
� ......
Oracle时间日期操作
sysdate+(5/24/60/60) 在系统时间基础上延迟5秒
sysdate+5/24/60 在系统时间基础上延迟5分钟
sysdate+5/24 在系统时间基础上延迟5小时
sysdate+5 在系统时间基础上延迟5天
add_months(sysdate,-5) 在系统时间基础上延迟5月
add_months(sysdate,-5*12) 在系统时间基础上延迟5年
上月末的日期：sel ......
