⑴ oracle进程号在process查不到
如果您在使用Oracle数据库时，在process中无法找到某个进程号，可能有以下几种虚拆情况：
1. 进程已经结束：如果该进程已经结束，则您在process中将无法找到该进程号。您可以尝试使用历史记录等方式查看该进程的状态。
2. 没有足够的权宴誉前限：如果您没有足够的权限访问Oracle数据库，则可能会导致无法查看某些进程号。请确保您的用户具有足够的权限。
3. 进程号被重用：如果Oracle数据库已经重启过，那么在process中可以看到之前使用过的进程号被重新分配给其他新进程使用，导致您无法找到原来的进程号。
4. 数据库问题：如果您遇到其他问题，例如Oracle数据库出现问题或崩溃，也可能导致您无法在process中找到某个进程号。
总之，如果您在process中无法找到某个Oracle进程号，请先检查以上几种情况，如果问题仍无法晌清解决，建议联系数据库管理员或者Oracle技术支持进行进一步排查和处理。
⑵ oracle存储过程失效重启后恢复正常
根据oracle数据库的特点和提供的工具，主要方法有以下几种方法：
利用逻辑备份使用import工具丢失数据的表
利用物理备份来通过还原数据文件并进行不悉高完全恢复
利用dbms_logmnr包从redo log文件中恢复
利用flashback特性恢复数据
前提
为了方便使用方法的介绍，上述恢复方法都将基于以下场景进行：系统管理员在前一天晚上11点用export对数据库做了全库逻辑备份，然后对所有数据文件进行了热备份。第二天上午10点，系统管理员在修改表TFUNDASSET的数据时，由于修改语句的条件写错了，导致一批记录(几千条)的ztm字段被修改成了错误的值，而且已经提交。这个表是资产表，相对而言数据变化不频繁。
一、利用逻辑备份使用import工具恢复丢失的数据
export/import是oracle提供的用于对数据库进行逻辑备份的工具。该工具适用于备份那些数据量不大、业务量不多的数据库系统。因为如果在前一天晚上11点用export做了逻辑备份，那么当今天上午10点数据库意外崩溃时，从备份起到数据库崩溃的这段时间里的数据修改操作(包括DDL和DML)都会丢失。如果丢失数据内的表上的数据是相对比较稳定，也就是说该表上基本没有DML操作，例如标准代码表、分区表里的历史数据，那么采用import来导入该表可以比较完整的恢复数据。如果该表是经常变化的业务表，那么这些丢失的数据只能根据业务情况从纸质记录恢复，或者其他途径恢复。
▲示例如下：这个表是一个资产表。相对来说，今天系统运行中修改的数据较少，丢失的数据量可以承受或者可以从别的途径恢复。那就可以用import来恢复。
方法一：
1、把这个表的数据备份到另一个表：
.png
2、删除该表的记录:
.png
3、执行下面的命令：
.png
这个命令中在关键字tables中指定需要导入的表名字，ignore=y表示忽略表已经存在的错误。
4、导入结束后，检查表中的记录，并用适当的方法恢复当天的修改。
方法二：
1、 把需要恢复的表导入到另一个用户下面：
.png
2、检查数据以后，把原表记录删除：
.png
3、然后从另一用户表中插入回去：
.png
4、 数据量比较大时可以采用如下方法：
.png
二、利用物理备份来通过还原数据文件并进行不完全恢复
如果数据库运行在归档模式下，那么可以通过使用以前的数据文件备份进行还原，然后利用归档日志进行前滚，直到回滚到错误操作的时间点前，然后重置日志文件打开数据库。
可以通过下列方法确认是否是运行在归档模式：
.png
如果是如上所示，那么就是运行在归档模式了。
▲假定在前一天晚上11点做了全库物理备份，那么可以考虑如下恢复：
1、关闭数据库：
由于数据库的不完全恢复必须在一个关闭的数据库上实施，利用一个旧的数据库的备份还原，然后用日志根据需要逐步前滚，而不能还拆扒原一个新的备份，再回退到某个时间点。
通知各客户端数据库将关闭，然后旅陆昌发出：
.png
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
2、确定错误操作的时间：
可以根据操作员的估计来确定不完全恢复需要前滚停止的时间，也可以利用LogMiner来分析日志文件(这个工具将在后面介绍)，找出错误操作的准确时间。
3、还原数据文件：
先对当前的数据库文件进行备份，然后再用以前的最近一次备份覆盖现有数据文件。注意：不覆盖现有的控制文件。
4、基于时间点恢复，启动数据库到装配状态：
.png
这样数据库就恢复到了2015年10月20日的9点58分零秒。
然后再利用业务资料补充这段时间内的数据。
三、利用dbms_logmnr包从log文件中恢复
这个包是由Oracle提供，与dbms_logmnr_d包配合使用可以方便地分析联机日志文件和归档日志文件，从这些日志文件中提取出所有对数据库的更改操作。
在使用这个包之前，需要先做一些设置和修改：
1、打开initorcl.ora，修改初始化参数utl_file_dir，设置dbms_logmnr_d包将要使用的数据字典文件的放置目录。
.png
然后重启数据库使参数生效。
2、以sys用户连接到数据库执行dbmslmd.sql脚本重建dbms_logmnr_d这个包。
应用Logminer分析重做日志文件的操作主要有以下步骤：
● 使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件；
● 使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件；
● 使用dbms_logmnr里的存储过程start_logmnr启动分析；
● 查询与dbms_logmnr相关的几个视图来获取日志文件内容；
● 使用dbms_logmnr里的存储过程end_logmnr结束分析。
▲下面详细讲述使用的过程
1、使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件：
.png
2、使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件到待分析文件列表：
.png
如果没有运行在归档模式，那么由于重做日志文件的循环使用可能导致日志文件被覆盖而无法获取到所要寻找的恢复条目。如果运行在归档模式，则可以通过查看$ORACLE_HOMEadminorclbmp目录下的alert_orcl.log里日志文件归档的时间和错误操作的时间来确定加入哪些归档日志文件到待分析的文件列表中去。
.png
注意：执行以上过程时logfilename参数需要写日志文件的全路径，否则会报错。重复以上操作直到把所有需要分析的文件都加到列表中去。这样就可以启动进行分析。
3、使用dbms_logmnr里的存储过程start_logmnr启动分析；
.png
这样就可以通过下面的查询来获取日志文件的内容了。
4、查询与dbms_logmnr相关的几个视图来获取日志文件内容；
.png
这样就可以找出要恢复所需的语句。注意：v$logmnr_contents只对执行dbms_logmnr.start_logmnr的会话有效，如果通过其他会话或者使用dbms_logmnr.end_logmnr终止了分析，都将不能访问v$logmnr_contents的数据。如果要使其他会话也能获取到这些数据，可以通过另外建表来实现，如：
create table undo_sql as select * from v$logmnr_contents。
再对undo_sql进行授权，其他用户就可以访问v$logmnr_contents的数据了。
5、使用dbms_logmnr里的存储过程end_logmnr结束分析。
使用完成以后用下面的命令来结束分析活动：exec dbms_logmnr.end_logmnr;
这样就释放了分配给logminer的资源(内存和数据结构)。
从上面的过程可知，如果是更新的数据量比较大，而日志文件比较小，就可能会导致日志文件的切换。如果没有及时去挖掘日志文件(没有运行在归档模式)，那么可能会由于日志文件的循环使用而导致数据不可恢复。如果运行在归档模式，也可能由于需要分析的日志文件比较多而时间较长。
四、利用flashback新特性恢复数据
Oracle9i 开始提供了闪回查询(Flashback Query)功能，对于误删除或者误更新并且已经commit了的情况提供了简便快捷的恢复方法；而在Oracle 提供闪回查询之前，碰到这种情况只能通过备份来进行基于时间点的恢复或者使用logmnr挖掘日志来恢复，无疑这比闪回查询要麻烦而且费时。
使用这个Flashback Query特性的前提条件：
1. 数据库必须处于Automatic Undo Management 状态。
.png
2. 最大可以闪回查询的时间段由UNDO_RETENTION 初始化参数(单位为秒)指定
.png
可以通过ALTER SYSTEM SET UNDO_RETENTION = ;来动态修改参数值。
▲如何使用Flashback Query来恢复数据呢？
1. 通过SQL
.png
使用SELECT 语句的AS OF 来进行闪回查询，语法如下：
使用AS OF 关键字来对表，视图或者物化视图进行Flashback Query，如果指定了SCN，那么expr 部分必须是一个数字，如果指定了TIMESTAMP，那么expr 必须是一个timestamp类型的值。查询结果将返回在指定的SCN 或者时间点上的数据。
下面我们使用scott 方案来作一个实验。
.png
如果想在update 的子查询部分使用AS OF，那么该查询只能返回一条记录，否则将会报错。
可以通过添加一个临时表作为中转，然后再作更新，如下：
.png
2．通过DBMS_FLASHBACK包来恢复
DBMS_FLASHBACK 包提供了以下几个函数：
ENABLE_AT_TIME：设置当前SESSION 的闪回查询时间
ENABLE_AT_SYSTEM_CHANGE_NUMBER：设置当前SESSION 的闪回查询SCN
GET_SYSTEM_CHANGE_NUMBER：取得当前数据库的SCN
DISABLE：关闭当前SESSION 的闪回查询
当将一个SESSION 设置为闪回查询模式之后，后续的查询都会基于那个时间点或者SCN 的数据库状态，如果SESSION 结束，那么即使没有明确指定DISABLE，闪回查询也会自动失效。
当SESSION 运行在闪回查询状态时，不允许进行任何DML 和DDL 操作。如果要用DML操作来进行数据恢复就必须使用PL/SQL 游标。
▲示例：
.png
通过上面的例子可以看出，只要这个修改的时间不早于sysdate- (UNDO_RETENTION指定的秒数),就可通过这种方式来恢复数据。
.png
对于问题中的批量数据，可以写个过程来完成获取到更改前的数据：
然后再用这个临时表里的数据来更新TFUNDASSET就可以了。
五、总结
比较以上几种恢复数据的方法的使用过程，我们可以看出：
● exp/imp只适合于数据变化不大的表的数据丢失的情况，即使用这种方法处理后也需要从业务办理资料中修正数据，否则导致数据丢失；
● 采用基于时间点的不完全恢复可以恢复丢失的数据，但是需要关关闭数据库，减少系统可用时间，而且也会丢失恢复时间点以后的数据；
● 使用LogMiner可以较好的恢复数据，但是要求数据库尽可能运行在归档模式，否则也可能导致数据丢失。好处是不用关闭系统，能够从日志文件中得到所有的数据。
● 使用Flashback最方便和简洁，可以直接得到修改前的数据，但是需要依赖系统设置，并且需要占用大量的回滚表空间。
因此选择什么样的方法来恢复数据，取决于你的系统环境和具体情况，不能生搬硬套。采用正确的方法才能最大程度的减少数据的丢失。
当然，最好是不需要用到这些恢复的办法。前提是，你必须做好以下的工作：
1、 为不同环境创建不同的数据库用户、不同密码(如果不能用户不同，一定要密码不同)；
2、 将owner和应用用户分开，并做适度授权；
3、 在做DML前，先用同样的条件做查询，看根据结果集是否符合预期。
⑶ 详细讲解Oracle数据库运行错误的解决方法
Oracle数此迟巧据库运行错误的解决方法
错误 ORA : ORACLE not available
Oracle安装 启动后用sqlplus / as sysdba 登陆 执行任何select语句都出现错误
select*fromdictionary * ERRORatline : ORA :ORACLEnotavailable
但是用toad等客户端工具正常!
为什么sqlplus不行呢?
另 我用的是
oracle
redhat as
解决方法:
更改一下linux用户的环境变量ORACLE_SID就可以了
错误 ORA : shared memory realm does not exist
我试图连接数据库时的ORA 和 ORA 错误信息 它总是显示这样的信息 ORA Oracle not available 和 ORA shared memory realm does not exist
不能连接到我的Oracle 数据库上
因为碰到防火墙森键的问题次数比较多 这次也先看看 发现根本就没什么拦截的 查看了一下监听 数据库旦迹实例也是运行着的
奇怪的事情 刚才还好好的 重启了机器就不行了
解决方法:解决的方法倒是不麻烦
首先看一下 ORACLE_BASEORACLE_HOMEDATABASE 下面的 ORADIM LOG 文件
如果里边有这个错误
ORA : 验证适配器初始化失败
那么问题就是它了
到ORACLE_BASEORACLE_HOMENEORKADMIN下面找sqlnet ora文件
把sqlnet authentication_services=(NTS) 改成
sqlnet authentication_services=(NONE)
然后手动重起一下你的哪个数据库服务 在开始 >控制面板 >管理工具 >服务里然后把这个服务的启动帐号改成你的帐号吧 其实不改大概也没有毛病 我就没改 看了这个方法 出错的原因大概有两种情况 修改了帐户 实例有些变动等
如果还不行 重启电脑试试
ERROR ORA : TNS:listener does not currently know of service requested in connect descriptor
关于 ORA: :TNS 没有监听器 的问题
看看是不是监听服务没有起来
检查有没有修改IP地址 计算机名称
对于 一般情况下是机器的IP地址更改了 我就碰到过这种情况 oracle g的安装是在没有联网的状态下 结果联上网后OracleDBConsole*服务启动不了 在此情况下我的解决方案是断网启动服务就好用了 其实问题在于初始配置的监听/服务中的主机信息与现在的信息不符 如果要改便主机IP/名称的话 也必须同时修改oracle中的相应配置 否则oracle找不到主机当然启动不了
必须启动的服务:OracleOraDb g_home TNSListener(监听器) OracleService[sid]这两项 后者可选为手动启动(因为吃资源厉害)
后来又遇到OracleOraDb g_home TNSListener服务无法启动的问题 google了下原来是被优化大师清注册表时干掉的 服务启动路径要在注册表中添加
方法如下
看HKEY_LOCAL_ TNSListener有无ImagePath的字符串 没有的话就加一个 值为 oracleproct db_ TNSLSNR(不只一处) 类似还有 优化大师干掉VS 中的 NET framework的注册表信息 当时我重装了
lishixin/Article/program/Oracle/201311/17611
⑷ oracle数据库服务宕机可能是什么原因造成的
原因很多，内部原因外部原谈橘伏因都有可能。
外部原因：比如服务器宕机，系统错误，温度过高宕机（比如机房空调坏了），临时断电，内存错误等等这些都有可能，电压不足等等。
内部原因：比较常见的有undo文件损坏，数据文件错误（遇到过一次，最后用补0的伍察方法扩大了数据文件才好，不过现在用asm存储，这个应该不怎么可能了），时间调整错误（向后调，改动时间过长，比如00:00改为01:00，那么就两个情况都占，未必一定宕机，不过可能性很大），核心进含携程错误（这个比较少见，不过真的有，有时是有人误杀了），程序错误导致（见过一个因为某程序错误，导致锁表，而后锁表导致某进程一直占用内存，后来的进程根本进不了该表，然后越滚越大最后宕机，还是后来查出来的，相当于蝴蝶扇翅膀变成飓风，所以有错误要及时发现才行），存储错误，io争用（持续时间长）等等。
这么说吧，很多的ora错误都可能引起宕机（并不是全部ora错误都会引起宕机），真要说的话要很长时间，如果想不宕机那么就要有监测检查制度，早发现早解决，也就不会有什么问题了。
⑸ 强制关闭oracle的危害
强制关闭 Oracle 数据库会带来以下危害：
1. 数据丢失或损坏。如果在关闭过程中正在进行写入操作，数据库可能只完成了部分修改操作并且没有把数据写入磁盘。此时数据库的数据可能出现不一致，导致数据的丢失和损坏，甚至使得数据库无法正常启动。
2. 数据库崩溃。一些数据库进程可能会继续在运行，例如，提交事务还没完成、查询语句还没执行完等等。如果数据库被强制关闭，这些进程可能无法正常退出，数据库就可能崩溃，导致系统棚型无法重启。
3. 数据库状态不稳定。强制关闭 Oracle 数据库可能导致某些系统资衡闷源受到损害。如果在关闭之后不及时进行修复，Oracle 数据库就可能一直处于不稳定的状态，影响其正常使用。
4. 数据库可用性降低。强制关闭 Oracle 数据库会破坏数据库的一致性和完咐和弯整性，使数据库无法正常工作。这对于用户和开发人员来说都是非常不利的，因为他们需要可靠的数据库来支持日常业务和开发。
因此，为了避免数据丢失、数据库崩溃和状态不稳定等问题出现，我们建议用户在关闭 Oracle 数据库之前，先进行相关的备份操作，并确保所有的操作完成之后再关闭数据库。再或者在必要情况下使用正常的关机过程来关闭数据库，避免使用强制关闭的方式。
⑹ ORA-03113错误分析
前言 每一个DBA在进行数据库管理的过程中不可避免的要遇到形形 *** 的错误(ORA xxxx) 有些错误由于频繁出现 原因复杂而被DBA们戏称之为 经典的错误 其中ORA end of fileon munication channel 就是这样的一个 我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断 不过 导致这个错误的原因实际上有很多种 对数据库设置不当 任何能导致数据库后台进程崩溃的行为都可能产生这个错误 这个错误的出现还经常伴随着其它错误 比如说 ORA ORACLE not available 此外 该错误出现的场景复杂 可能出现在: 启动的Oracle的时侯; 试图创建数据库的时侯; 试图对数据库进行连接的时侯; 在客户端正在运行SQL/PL/SQL的时侯; 备份／恢复数据库的时侯; 其它一些情况下．．．．．．在论坛上也时常可以看到初级DBA对这个问题的求救 在这里简单的对该问题睁歼进行一下整理 不当之处 请多指教！ 错误原因种种 根据网络上大家反映的情况来看 错误原因大约有这些: Unix核心参数设置不当 Oracle执行文件权限不正确／环境变量问题 客户端通信不能正确处理 数据库服务器崩溃/操作系统崩溃/进程被kill Oracle 内部错误 特定SQL PL/SQL引和早雀起的错误 空间不够 防火墙的问题 其它原因在开始解决问题之前 作如下几件事情: 回忆一下在出现错误之前你都做了什么操作 越详细越好; 查看background_mp_dest目录中的alertSID log文件也是你要做的事情; Google一下 在互联网上有很多信息等着你去发现 不要什么都问别人 当然 如果你找到了一些对你非常有帮助的东西――这篇文档就不用看了 别耽误你的时间 呵呵 Unix核心参数设置不当/ init参数设置不当 如果数据库在安装过程中没有设定正确的操作系统核心变量 可能在安装数据库文件的时侯没甚么问题 在创建数据库的时侯常常会出现 错误 和此有关的另一个原因是init ora参数文件中的processes参数指定了不合理的值 启动数据库导致错误出现(当然这个归根到底也是核心参数的问题) 这个错误信息一般如下 ORA : end of file on munication channelORA : ORACLE not availableORA : shared memory realm does not exist解决办法有两个 修改核心参数 加大相应核心参数的值(推荐); 减小init ora参数的Processes的值 需要注意的是 SEMMSL必须设定为至少要 + 进程数的最大值 SEMMNS 也依赖于每个数据库上的进唤早程参数值 注 这个错误类型只在Unix平台上出现 在Windows上如果processes的值过大 则会出现 ORA : invalid value for parameter max_rollback_segments must bebeeen and /* 此时指定的参数值超过了 */或者ORA : out of memory/* 小于 的一个大参数值 */我的软件环境 Windows Version Service Pack CPU type ORACLE RDBMS Version: 在特定平台上更改核心参数可能会有差别 请参考Oracle Technet()上的安装文档 对特定Unix平台的安装文档也有对核心参数意义的解释 Init ora中的参数如果设置不当 会产生该错误 有经验表明:shared_pool_size设置过小会出现错误 此外timed_statistics=true的设置也会带来问题 Oracle执行文件权限不正确/环境变量问题 这个问题只出现在Unix平台上 常见情况是有的时侯管理员为了方便而使用Unix的tar命令处理过的压缩包进行的安装 或者是系统管理员指定了额外的OS用户也可以管理数据库却没有指定正确的环境变量 Oracle执行文件在$ORACLE_HOME/bin目录下 如果出现问题 应该用如下Unix类似命令来纠正 chmod $ORACLE_HOME/bin/oracle有的时侯要对Oracle进行relink操作 在Unix上通过cp拷贝安装的时候 常常会出现环境变量的问题 和个别执行程序连接问题 LD_LIBRARY_PATH如果设置的不正确会导致问题 在这种情况下 需要对Oracle进行relink 如果可执行文件oralcle被破坏 也要对其relink 如果安装了并行服务器选项而Distributed Lock Manager没有安装或正确运行也会导致错误 客户端通信不能正确处理 SQL*Net驱动器的问题 如果使用的版本比较低的驱动器 请更换到新版本的驱动 SQL*Net的驱动没有连接到Oracle可执行文件会导致错误 检查网络是否通畅 Windows平台的常见问题:在Windows平台创建数据库的时侯 如果出现该问题可以考虑用如下的方法 首先检查本地网络设置 查看网络上是否有同名的结点或有冲突的IP 如果问题依旧 可以保守的用下面的方法 禁用网卡 将本地连接状态改为禁用; 将sqlnet ora文件打开(以记事本形式)将nts验证注释掉 #SQLNET AUTHENTICATION_SERVICES= (NTS) 创建数据库; 创建成功后 恢复本地连接 数据库服务器崩溃/操作系统崩溃/进程被Kill 在连接过程中 如果Oracle数据库的服务器崩溃或者数据库所在的操作系统崩溃 就会出现这个错误 Oracle Server崩溃的原因可能因为主要后台进程死掉 被错误的进行了Kill操作 如果是这个原因还是比较容易解决的 此外 和OS有关的应用程序存在内存泄漏(或者有病毒)的时侯也会导致Oracle后台程序问题 推荐排错办法: 查看应用软件相关进程是否正常运行; 查看有无内存泄漏; 查杀病毒; 确定系统管理员没有进行误操作; 确定无黑客入侵行为 其它不确定因素．．．．．． Oracle 内部错误/ Bug 如果查看background_mp_dest目录中的alert log发现有无ora 等错误 可以到Metalink站点上查看具体信息及其解决方案 一般情况下要打软件补丁 特定SQL PL/SQL引起的错误尝试把SQL进行分开执行 也可以用SQL_TRACE来进行跟踪 找到导致问题的SQL语句 在SQLPlus下 ALTER SESSION SET SQL_TRACE TRUE;SQL语句中的非法字符和不合理的处理结果偶尔会带来问题 系统空间不够 任何时侯都要确保数据库系统有足够的空间 如果 USER_DUMP_DEST和BACKGROUND_DUMP_DEST没有剩余空间的话 会导致此问题 此外 如果打开了审计 AUDIT目录要由足够的空间 如果激活了Trace的话 Trace目录要由足够的空间 Dave Wotton的文档表明 在对表进行插入数据的时侯 如果文件超过了 G(而文件系统有 G限制) 会导致该问题 防火墙的问题 如果数据要通过防火墙 请联系系统管理员 询问是否对数据库数据进行了过滤或者是突然禁止了通行端口 如本地安装有个人防火墙 请检查本地设置 其它方面说明 导致这个错误的原因有很多种 上面列到的只是一些典型情况 经常去一些数据库技术论坛可能会有帮助 比如说ITPUB() C NOUG()等 lishixin/Article/program/Oracle/201311/17658
⑺ 让oracle数据库崩溃的sql语句
dml操作（insert , delete , update）之后，一定要使用commit或rollback命令来结束该事务，否则直接关闭sql plus，数据库默认rollback之前未提交的事漏唤御务，所以今天你在select的时候 会显示未选定行。
而手动输入commit,rollback 这类的命令，是显示的提交事务（完成事务）。
如果在dml操作之链源后未及时显示的提交，而是又进行了ddl操作（create alter...）,则数据返岩库会隐式的提交之前未完成的事务。
所以 下次一定要注意哦~~
⑻ 我的数据库突然崩溃了，不知道是什么原因
1，首先排除设置了正确的sid连接
如：c:\users\administrator>set
oracle_sid
=
orcl
//确定本机数据库实例名
linux下用export
oracle_sid=orcl
2，以sysdba连接，关闭数据库
sqlplus
/
as
sysdba
shutdown
immediate
如果不能关闭，windows下杀掉oracle进程，停掉oracle的服务
linux下：ps
-ef|grep
smon找到对应的pid
kill
-9
3,重新启动试试
startup
如果还是不行，查看报错原因，这里可能有很多，比如数据文件错误
4.这里假如你的错误是数据文件引起
shutdown
immediate
startup
mount
recover
datafile
;
alter
database
open;
就可以了
如果不是数据文件错误，贴出来看看吧
⑼ oracle数据库崩溃了怎么办
把原来数据库的数据文件、
日志文件、
控制文件
拷贝到新装数据库的目录下 然后STARTUP
⑽ oracle 导出dmp 会不会导致数据库崩溃
当然不会了，导出dmp是对数据库的备份，导出时会提示你需不需要导出数据和对象之类的。放心备份吧