oracle运行一段时间后，就自动停止，怎么回事？连接数据库时报送：ERROR: ORA-01034:

Posted 2023-04-24

这里是alert_sid.log：
Sat May 14 00:00:12 2011
Thread 1 advanced to log sequence 1277
Current log# 1 seq# 1277 mem# 0: /deve/oracle/app/oracle/oradata/oradb/redo01.log
Sat May 14 00:14:25 2011
Starting background process EMN0
EMN0 started with pid=15, OS id=10899
Sat May 14 00:14:25 2011
Shutting down instance: further logons disabled
Sat May 14 00:14:25 2011
Stopping background process CJQ0
Sat May 14 00:14:25 2011
Stopping background process MMNL
Sat May 14 00:14:26 2011
Stopping background process MMON
Sat May 14 00:14:27 2011
Shutting down instance (immediate)
License high water mark = 3
All dispatchers and shared servers shutdown
Sat May 14 00:14:29 2011
ALTER DATABASE CLOSE NORMAL
Sat May 14 00:14:29 2011
SMON: disabling tx recovery
SMON: disabling cache recovery
Sat May 14 00:14:29 2011
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 1277
Successful close of redo thread 1
Sat May 14 00:14:29 2011
Completed: ALTER DATABASE CLOSE NORMAL
Sat May 14 00:14:29 2011
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
SQL> show SGA;

Total System Global Area 1207959552 bytes
Fixed Size 1219088 bytes
Variable Size 318768624 bytes
Database Buffers 872415232 bytes
Redo Buffers 15556608 bytes

参考技术A Oracle DBA神器：PRM-DUL灾难恢复工具可以直接从这种受损的Oracle数据库中将数据拯救出来。
当你的数据库因为ORA-00600/ORA-07445或其他ORA-报错，或丢失关键的system表空间数据文件，或ASM diskgroup损坏时均可以考虑采用PRM-DUL来做恢复。PRM-DUL采用独创的DataBridge恢复技术，直接从数据文件中抽取数据后可以像DBLINK那样直接插入到新建数据库中，而无需数据落地成为DMP文件占用空间。 参考技术B 检查交换区是否耗尽，检查Oracle SGA设置是否过大。追问

是不是就是共享内存啊，需要设置大一些吗，共享内存是1G
SQL> show SGA;

Total System Global Area 1207959552 bytes
Fixed Size 1219088 bytes
Variable Size 318768624 bytes
Database Buffers 872415232 bytes
Redo Buffers 15556608 bytes

追答

交换区：在windows下也叫虚拟内存或页面文件。
共享内存的设置需要根据操作系统的情况设置，如果机器和系统的可用内存足够，应设置大点。

本回答被提问者采纳

Oracle数据库 ORA-01555快照过旧是怎么回事？怎么解决？

与你分享 ORA-01555 错误的几种解决方案，一般来说可以采用 下
面的方法：
适当地设置参数 UNDO_RETENTION （要大于执行运行时间最长的事务所需的时间）。可以用
V$UNDOSTAT 来确定长时间运行的查询的持续时间。另外，要确保磁盘上已经预留了足够的空间 ，
使 undo 段能根据所请求的 UNDO_RETENTION 增大。
使用手动 undo 管理时加大或增加更多的回滚段。这样在长时间运行的查询执行期间，覆 盖
undo 数据的可能性就能降低。
减少查询的运行时间（调优）。如果可能的话，这绝对是一个好办法，所以应该首先尝试 这
种方法。这样就能降低对 undo 段的需求，不需求太大的 undo 段。这种方法可以解决上述的所
有 3 个问题。
收集相关对象的统计信息。这有助于避免生成大的undo。由于大批量的 UPDATE 或INSERT 会导致块清除（ block cleanout ），所以需要在大批量 UPDATE 或大量加载之后以某种方
式收集统计信息。 还有一个就是重新设置大一点的undocreate undo tablespace undo_bigdatafile size 2g（让后用数据文件加到足够大）
autoextend off alter system set undo_tablespace = undo_big（切换） 参考技术A 用户user1对表进行了更新操作,用户user2在user1还没有进行提交前读表中数据,而且是大批量的读取(打个比方:耗时3分钟)而在这3分钟内user1进行了提交操作,那又会产生什么影响呢?这个时候怎么保证读写一致性呢?这个时候DBMS就要保证有足够大的undo表空间来存放修改前的数值,,以保证user2读取的数据是修改前的一致数据.然后下次再读取时候就是更新后的数据了.
ora-01555快照过旧就是因为undo空间不够大，其中一部分undo数据被覆盖了，用户无法获得修改前的数据。
undo数据分为三种：
活动的undo：未提交事务的undo数据，这些undo数据永远不能覆盖，用于回滚rollback事务。
过期的undo：已提交事务的undo数据，这些undo数据可以覆盖。
未过期的undo：事务已提交，但事务提交前，有些查询正在进行，它要读取的是提交前的数据，这部分数据就是未过期数据。如果这部分undo数据被覆盖了，就会发生ora-01555错误。

一个解决方法是，指定undo表空间参数UNDO_TABLESPACE，并将undo空间管理方法设置成自动扩展：UNDO_MANAGEMENT=AUTO。
这种方法可能产生的结果是：
因为undo表空间装了太多未过期（unexpired）的undo数据，新的transaction无法向其中写入undo数据，这时transaction就会发生ORA-30036错误。