oracle的卸载是一个比较麻烦的事，如果没有成功卸载或者卸载的不干净，往往会影响下次的安装。正确的步骤如下：

1. 关闭所有oracle的服务和程序
2. 选择开始| 程序|oracle Installation Products命令，运行Universal Installer，弹出欢迎对话框
3. 单机 卸载产品 按钮，弹出Inventory对话框
4. 选中Inventroy对话框中的所有节点，点击删除，确认即可
5. 选 择 开始|运行 输入regedit并按ENTER键，选择HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE，删除此象，然后选择 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services，滚动此列表，删除与oracle有关的所 有选项。
6. 从桌面上、STARTUP和程序菜单中删除所有ORACLE的组和图标。
7. 重启系统。
8. 删除包括文件在内的安装目录。至此ORACLE的全部卸载完成。

     摘要: update：这个例子是不当的，更合适的例子请自己上javaeye上搜索个帖子。源码俺早就丢了，请不要再发邮件给我，谢谢。       osworkflow扩展非常容易，跟我们的应用结合起来使用也很容易。假设一个请假流程：员工请假，需要经过部门经理和人力资源部经理两人共同审批，只有当两人都许可时才通过，任一人驳回就失效，也就是一个and split和and Joi...  阅读全文      摘要: oracle sql语句优化的常见原则  阅读全文 在导入一个2G的备份文件时，数据库报ORA-00257故障，找到这篇文章。转自http://dev.yesky.com/438/2525938.shtml

概述：

　　Oracle数据库是目前业界最常用的大型数据库系统，我在实际项目中遇到出现ORA-00257错误（空间不足错误），通过查找资料，绝大部分说这是由于归档日志太多，占用了全部的硬盘剩余空间导致的，通过简单删除日志或加大存储空间就能够解决。但是我在Oracle 10g上发现，存储空间还有很大，却也报这个错误。原来是Oracle 10g中新的特性，对Flash Recovery的管理导致的。

　　1、软硬件环境

　　服务器HP Proliant DL580G4（Intel Xeon 3.16GHz/4GB/ 72.8*4/RAID4)

　　操作系统Red Flag DC Server release 5.0 (Trinity) for x86-64 Linux

　　数据库Oracle 10.2.0.1.0

　　2、问题现象

　　数据库系统已经试运行了半个多月，在7月24日晚上连接数据库后做数据更新时出现ORA-00257错误，如下图。


　　提示归档错误，通过查找ORACLE错误代码，解释为硬盘空间不足，需要删除归档日志增加空间，但是服务器可用空间200GB，目前只用了10GB左右，这是为什么呢？

　　3、诊断过程：

　　1）查看ORACLE数据库归档日志情况

[root@hrmsdb /]# cd /oracle/flash_recovery_area/HKCHR/archivelog [root@hrmsdb archivelog]# ls 2006_07_04 2006_07_13 2006_07_17 2006_07_20 2006_07_23 2006_07_11 2006_07_14 2006_07_18 2006_07_21 2006_07_24 2006_07_12 2006_07_15 2006_07_19 2006_07_22 2006_07_25 [root@hrmsdb archivelog]# cd 2006_07_25 [root@hrmsdb 2006_07_25]# ls [root@hrmsdb 2006_07_25]# cd ../2006_07_24 [root@hrmsdb 2006_07_24]# ls o1_mf_1_92_2d933vgb_.arc o1_mf_1_96_2d954ns7_.arc o1_mf_1_98_2d969d5h_.arc o1_mf_1_95_2d9537cs_.arc o1_mf_1_97_2d956km0_.arc

　　说明在出现问题之前数据库归档处理一直是正常的。

　　2）查看数据库REDOLOG情况

[oracle@hrmsdb ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.1.0 - Production on 星期二 7月 25 10:44:18 2006 Copyright (c) 1982, 2005, Oracle. All rights reserved. SQL> connect / as sysdba 已连接。 SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- --------------------------------------- -------------- 1 1 101 52428800 1 NO CURRENT 3621973 24-7月 -06 2 1 99 52428800 1 NO INACTIVE 3600145 24-7月 -06 3 1 100 52428800 1 NO INACTIVE 3611932 24-7月 -06

　　发现ARC状态为NO，表示系统没法自动做归档。

　　3）手工切换日志

SQL> alter system switch logfile; alter system switch logfile * 第 1 行出现错误:

　　ORA-01013: 用户请求取消当前的操作

　　在等待长时间没反应后，中断操作，手工切换日志没有成功。

　　4）查看Oracle数据库后台归档服务进程

[oracle@hrmsdb ~]$ ps -ef|grep oracle oracle 4601 1 0 Jul11 ? 00:00:04 /oracle/product/10.2.0/db_1/bin/ tnslsnr LISTENER -inherit oracle 5025 1 0 Jul11 ? 00:00:00 /usr/bin/ssh-agent -s oracle 20923 1 0 Jul24 ? 00:00:01 ora_pmon_hkchr oracle 20925 1 0 Jul24 ? 00:00:00 ora_psp0_hkchr oracle 20927 1 0 Jul24 ? 00:00:00 ora_mman_hkchr oracle 20929 1 0 Jul24 ? 00:00:01 ora_dbw0_hkchr oracle 20931 1 0 Jul24 ? 00:01:07 ora_lgwr_hkchr oracle 20933 1 0 Jul24 ? 00:00:05 ora_ckpt_hkchr oracle 20935 1 0 Jul24 ? 00:00:01 ora_smon_hkchr oracle 20937 1 0 Jul24 ? 00:00:00 ora_reco_hkchr oracle 20939 1 0 Jul24 ? 00:00:00 ora_cjq0_hkchr oracle 20941 1 0 Jul24 ? 00:00:01 ora_mmon_hkchr oracle 20943 1 0 Jul24 ? 00:00:05 ora_mmnl_hkchr oracle 20945 1 0 Jul24 ? 00:00:00 ora_d000_hkchr oracle 20947 1 0 Jul24 ? 00:00:00 ora_s000_hkchr oracle 20953 1 0 Jul24 ? 00:09:41 ora_arc0_hkchr oracle 20955 1 1 Jul24 ? 00:10:29 ora_arc1_hkchr oracle 20959 1 0 Jul24 ? 00:00:00 ora_qmnc_hkchr oracle 20967 1 0 Jul24 ? 00:00:00 ora_q000_hkchr oracle 20969 1 0 Jul24 ? 00:00:00 ora_q001_hkchr oracle 21715 1 0 Jul24 ? 00:00:19 oraclehkchr (LOCAL=NO) oracle 21765 1 0 Jul24 ? 00:00:00 ora_j000_hkchr oracle 21816 1 0 Jul24 ? 00:00:00 ora_j001_hkchr oracle 21832 1 0 Jul24 ? 00:00:00 ora_j002_hkchr oracle 21839 1 0 Jul24 ? 00:00:00 ora_j003_hkchr oracle 21859 1 0 Jul24 ? 00:00:00 ora_j004_hkchr oracle 21861 1 0 Jul24 ? 00:00:00 ora_j005_hkchr oracle 21886 1 0 Jul24 ? 00:00:00 ora_j006_hkchr oracle 21888 1 0 Jul24 ? 00:00:00 ora_j007_hkchr root 23187 23186 0 10:39 ? 00:00:00 login -- oracle oracle 23188 23187 0 10:39 pts/0 00:00:00 -bash oracle 23216 23188 0 10:39 pts/0 00:00:00 sqlplus oracle 23217 23216 0 10:39 ? 00:00:00 oraclehkchr (DESCRIPTION=(LOCAL= YES)(ADDRESS=(PROTOCOL=beq))) root 23224 23223 0 10:40 ? 00:00:00 login -- oracle oracle 23225 23224 0 10:40 pts/1 00:00:00 -bash oracle 23310 23225 0 10:46 pts/1 00:00:00 ps -ef oracle 23311 23225 0 10:46 pts/1 00:00:00 grep oracle [oracle@hrmsdb ~]$ 后台进程都正常运行。

　　5）查看FLASH_RECOVERY_AREA空间使用情况

[root@hrmsdb /]# cd /oracle [root@hrmsdb oracle]# ls admin flash_recovery_area oraInventory product [root@hrmsdb oracle]# du -a -k flash_recovery_area 4 flash_recovery_area/HKCHR/onlinelog 42456 flash_recovery_area/HKCHR/archivelog/2006_07_15/o1_mf_1_74_2cj1h1jz_.arc ………………. 42448 flash_recovery_area/HKCHR/archivelog/2006_07_14/o1_mf_1_68_2cfzwwvt_.arc 512560 flash_recovery_area/HKCHR/archivelog/2006_07_14 1469224 flash_recovery_area/HKCHR/archivelog 6988 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_ncsnf_TAG20060704T1 74229_2bng1o0b_.bkp 876916 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_nnndf_TAG20060704T1 74229_2bng0cx4_.bkp 883908 flash_recovery_area/HKCHR/backupset/2006_07_04 883912 flash_recovery_area/HKCHR/backupset 2353144 flash_recovery_area/HKCHR 2353148 flash_recovery_area [root@hrmsdb oracle]# FLASH_RECOVERY_AREA空间使用了2.35GB

　　6）查看FLASH_RECOVERY_AREA空间中各部分使用情况

SQL> select * from v$recovery_file_dest; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ------------------------------------------------------------------------------------------------------------------ /oracle/flash_recovery_area 2147483648 2134212608 0 35 SQL> select * from v$flash_recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- ---------------- -------------- -------------- ------------- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG 69.97 0 40 BACKUPPIECE 30.01 0 2 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0 已选择6行。

　　发现ARCHIVELOG占近70％，BACKUPPIRCR占了30％，这样FLASH_RECOVERY_AREA空间的空间已经被完全占据了。
4、解决过程

　　根据数据库目前可用存储空间为200GB、FLASH_RECOVERY_AREA空间为2GB的实际情况，把FLASH_RECOVERY_AREA的空间修改为20GB。

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g; 系统已更改。 SQL> select * from v$recovery_file_dest; ------------------------------------------------------- ---------- ----------------------------------- NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ----------- ---------- ----------------- ------------- -------------- ---------- ---------- ------------ /oracle/flash_recovery_area 2.1475E+10 2264587776 0 38

　　这时再查看日志的状态，发现REDO LOG处于正常的归档状态。

SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- -------------------------------------------- -------------- 1 1 101 52428800 1 YES ACTIVE 3621973 24-7月 -06 2 1 102 52428800 1 NO CURRENT 3650399 25-7月 -06 3 1 100 52428800 1 YES INACTIVE 3611932 24-7月 -06 SQL> select * from v$flash_recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- --------------- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG 7.6 0 43 BACKUPPIECE 4.21 0 2 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0 已选择6行。 SQL>

　　5、小结

　　造成本次故障的原因由两方面同时发生所造成的：

　　·其一是Flash_Recovery_Area空间缺省安装时比较小，只有2GB，容易用完；

　　·其二是由于采用归档方式通过Veritas备份，由于备份软件没有运行，造成归档日志没有及时删除。

　　从本次故障解决处理中，我们可以得出经验教训：

　　·Oracle 10g数据库物理空间管理方式与以前Oracle发生了变化，对归档日志所在的Flash_Recovery_Area空间进行了另外限制；
　
　　·对数据库系统管理员要对Oracle数据库归档日志、备份软件运行状况定期检查，提前发现、处理可能发生的故障。
    昨天根据客户要求，增加了一个jasperreport实现的报表打印功能，然后在测试服务器上测试通过，因为看到测试数据库上的数据都太“旧”了，我就从正式环境下导出了OA系统的数据，导出操作一切顺利，在导入过程中却由于网络问题中断（因为我是远程导入，备份文件在我的机器上）。再次连接数据库，一直报错，说什么只允许内部连接。远程重启了下oracle服务，登录数据库还是不行，发现数据库根本没打开，通过sqlplus执行
    命令，报错：

看情况是日志文件出错，幸好是测试服务器，把我这个对oracle管理一窍不通的家伙急坏了。马上baidu了下错误代码，找到一篇文章：

在日志文件损坏或者dump这些损坏的日志文件的时候，通常回收到类似下面的错误：

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 3740 change 0 time 04/11/2006 13:49:56  

ORA-00312: online log 1 thread 1: '/oracle/oradata/TSMISC02/redo01.log'

或者：

sys@TSMISC02> ALTER SYSTEM DUMP LOGFILE '/oracle/oradata/TSMISC02/redo01.log';

ALTER SYSTEM DUMP LOGFILE '/oracle/oradata/TSMISC02/redo01.log'

*

ERROR at line 1:

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 3740 change 6918597 time 04/10/2006 23:53:24

ORA-00334: archived log: '/oracle/oradata/TSMISC02/redo01.log'

Elapsed: 00:00:03.36

sys@TSMISC02>

这里首先介绍一下oracle使用日志文件的策略。每一个数据库至少有两个或多个日志文件组（redo log group），每个组中至少有一个日志成员（redo log member）。日志文件的主要功能是真实完整的记录对数据库作的全部修改。在出现故障时，如果不能将修改数据永久地写入数据文件，则系统将利用日志前滚来恢复数据库数据文件。日志文件主要是保护数据库以防止故障。

如果LGWR 至少能够访问一个组内的某一个成员，那么oracle就会对这个组内的可访问成员继续照常进行读写操作，也就是说，LGWR 将忽略组内的不可用成员。如果在日志切换时LGWR 无法访问下一个组的所有成员或者损坏的日志文件时改组中日志成员，数据库的正常操作就无法进行了。这也就是oracle常说的，为了防止日志文件的故障或丢失，强烈建议镜象日志(mirrored redo log)，即，在不同磁盘上维护至少两个或多个日志文件（redo log member）副本的作用——只要组内有一个可用的成员，oracle就会继续“正常”操作。

回到这里，如果数据库发生日志文件的上述损坏，不管是哪种原因造成的，解决方法无外乎是使用完好的文件恢复已经损坏的文件，或者初始化损坏的文件组等等（日志文件的故障处理不做这里的重点介绍，我将会在其他的文章中逐一说明和举例）。

我们这里主要是使用了_disable_logging＝true这个隐含参数（实际性能故障诊断时，你可以通过alert.log找到相关信息）造成了归档数据库中，所有日志不能归档，最终数据库不能继续操作的问题，因此解决方法就是：

（a）如果是使用了隐含参数，那么去掉这个隐含参数：

    alter system set "_disable_logging"=false scope=both;

（b）然后，初始化损坏的redo log：

alter database clear unarchived logfile '<logilename>'; 

例如：

sys@TSMISC02> alter system set "_disable_logging"=false scope=both;

System altered.

Elapsed: 00:00:00.01

sys@TSMISC02>

sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo02.log'; 

Database altered.

Elapsed: 00:00:00.18

sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo03.log'; 

Database altered.

Elapsed: 00:00:00.17

sys@TSMISC02>

OK,马上执行命令：

alter database clear unarchived logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG'

再打开数据库，一切正常，重新导入，问题解决。

我需要加强下对oracle基本故障处理方面知识的学习了。