#求助#Oracle实例总是自动关闭(在线等)

xozhangyi 2017-06-02 03:08:55
情况:
windows 2008 server
Oracle 11g 2.0.2非RAC

问题:
一直正常运行1年多,最近突然无法连接,检查发现windows服务(OracleServiceSID)会自动关闭;
进一步发现,mounted状态时,服务不掉;
一旦startup数据库,服务就会掉;

操作:
重做一个相同环境数据库,将数据文件、控制文件等整体迁移,问题依然存在;

alter部分日志:


Fri Jun 02 16:12:12 2017
QMNC started with pid=27, OS id=6616
Completed: alter database open
Starting background process CJQ0
Fri Jun 02 16:12:13 2017
CJQ0 started with pid=29, OS id=7040
Fri Jun 02 16:12:13 2017
db_recovery_file_dest_size of 40960 MB is 34.56% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Setting Resource Manager plan SCHEDULER[0x310A]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Starting background process VKRM
Fri Jun 02 16:12:16 2017
VKRM started with pid=28, OS id=6604
Fri Jun 02 16:12:19 2017
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC
Stopping background process CJQ0
Stopping background process MMNL
Stopping background process MMON
License high water mark = 8
Stopping Job queue slave processes, flags = 7
Job queue slave processes stopped
All dispatchers and shared servers shutdown
ALTER DATABASE CLOSE NORMAL
Fri Jun 02 16:12:22 2017
SMON: disabling tx recovery
SMON: disabling cache recovery
Fri Jun 02 16:12:22 2017
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 32189
Successful close of redo thread 1
Completed: ALTER DATABASE CLOSE NORMAL
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Fri Jun 02 16:12:23 2017
Stopping background process VKTM
Fri Jun 02 16:12:25 2017
Instance shutdown complete
Fri Jun 02 16:12:32 2017
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =126
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile E:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\SPFILESN67.ORA
System parameters with non-default values:
processes = 750
java_pool_size = 128M
nls_length_semantics = "BYTE"
memory_target = 26240M
control_files = "E:\APP\ADMINISTRATOR\ORADATA\SN67\CONTROL01.CTL"
control_files = "E:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\SN67\CONTROL02.CTL"
db_block_size = 8192
compatible = "11.2.0.0.0"
db_recovery_file_dest = "e:\app\Administrator\fast_recovery_area"
db_recovery_file_dest_size= 40G
undo_tablespace = "UNDOTBS1"
db_securefile = "PERMITTED"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=SN67XDB)"
audit_file_dest = "E:\APP\ADMINISTRATOR\ADMIN\SN67\ADUMP"
audit_trail = "DB"
sort_area_size = 131072
db_name = "SN67"
open_cursors = 750
optimizer_capture_sql_plan_baselines= FALSE
optimizer_use_sql_plan_baselines= FALSE
diagnostic_dest = "E:\APP\ADMINISTRATOR"
Fri Jun 02 16:12:33 2017
PMON started with pid=2, OS id=6472
Fri Jun 02 16:12:33 2017
PSP0 started with pid=3, OS id=6828
Fri Jun 02 16:12:35 2017
VKTM started with pid=4, OS id=6896 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Fri Jun 02 16:12:35 2017
GEN0 started with pid=5, OS id=6040
Fri Jun 02 16:12:35 2017
DIAG started with pid=6, OS id=928
Fri Jun 02 16:12:35 2017
DBRM started with pid=7, OS id=6760
Fri Jun 02 16:12:35 2017
DIA0 started with pid=8, OS id=6992
Fri Jun 02 16:12:35 2017
MMAN started with pid=9, OS id=5612
Fri Jun 02 16:12:35 2017
DBW0 started with pid=10, OS id=6340
Fri Jun 02 16:12:35 2017
LGWR started with pid=11, OS id=6596
Fri Jun 02 16:12:35 2017
CKPT started with pid=12, OS id=7012
Fri Jun 02 16:12:35 2017
SMON started with pid=13, OS id=6156
Fri Jun 02 16:12:35 2017
RECO started with pid=14, OS id=6720
Fri Jun 02 16:12:35 2017
MMON started with pid=15, OS id=6708
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Jun 02 16:12:35 2017
MMNL started with pid=16, OS id=6276
starting up 1 shared server(s) ...
ORACLE_BASE from environment = e:\app\Administrator
Fri Jun 02 16:12:35 2017
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 2614104627
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Fri Jun 02 16:12:39 2017
ALTER DATABASE OPEN
Thread 1 opened at log sequence 32189
Current log# 5 seq# 32189 mem# 0: E:\APP\ADMINISTRATOR\ORADATA\SN67\REDO05.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
[6888] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:72860422 end:72860469 diff:47 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Fri Jun 02 16:12:39 2017
QMNC started with pid=20, OS id=4824
Completed: ALTER DATABASE OPEN
Starting background process CJQ0
Fri Jun 02 16:12:40 2017
CJQ0 started with pid=22, OS id=6608
Fri Jun 02 16:12:40 2017
db_recovery_file_dest_size of 40960 MB is 34.56% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Setting Resource Manager plan SCHEDULER[0x310A]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Starting background process VKRM
Fri Jun 02 16:12:43 2017
VKRM started with pid=23, OS id=5872
= "DB"
sort_area_size = 131072
db_name = "SN67"
open_cursors = 750
optimizer_capture_sql_plan_baselines= FALSE
optimizer_use_sql_plan_baselines= FALSE
diagnostic_dest = "E:\APP\ADMINISTRATOR"
Thu Jun 01 19:58:45 2017
PMON started with pid=2, OS id=4416
Thu Jun 01 19:58:45 2017
PSP0 started with pid=3, OS id=4424
Thu Jun 01 19:58:46 2017
VKTM started with pid=4, OS id=4464 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Jun 01 19:58:47 2017
GEN0 started with pid=5, OS id=4468
Thu Jun 01 19:58:47 2017
DIAG started with pid=6, OS id=4472
Thu Jun 01 19:58:47 2017
DBRM started with pid=7, OS id=4476
Thu Jun 01 19:58:47 2017
DIA0 started with pid=8, OS id=4480
Thu Jun 01 19:58:47 2017
MMAN started with pid=9, OS id=4484
Thu Jun 01 19:58:47 2017
DBW0 started with pid=10, OS id=4488
Thu Jun 01 19:58:47 2017
LGWR started with pid=11, OS id=4492
Thu Jun 01 19:58:47 2017
CKPT started with pid=12, OS id=4496
Thu Jun 01 19:58:47 2017
SMON started with pid=13, OS id=4500
Thu Jun 01 19:58:47 2017
RECO started with pid=14, OS id=4504
Thu Jun 01 19:58:47 2017
MMON started with pid=15, OS id=4508
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = e:\app\Administrator
Thu Jun 01 19:58:47 2017
MMNL started with pid=16, OS id=4512
Thu Jun 01 19:58:48 2017
alter database mount exclusive
Successful mount of redo thread 1, with mount id 2613980344
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Beginning crash recovery of 1 threads
parallel recovery started with 7 processes
Started redo scan
Completed redo scan
read 97 KB redo, 70 data blocks need recovery
Started redo application at
Thread 1: logseq 32183, block 4407
Recovery of Online Redo Log: Thread 1 Group 5 Seq 32183 Reading mem 0
Mem# 0: E:\APP\ADMINISTRATOR\ORADATA\SN67\REDO05.LOG
Completed redo application of 0.07MB
Completed crash recovery at
Thread 1: logseq 32183, block 4601, scn 245868132
70 data blocks read, 70 data blocks written, 97 redo k-bytes read
Thread 1 advanced to log sequence 32184 (thread open)
Thread 1 opened at log sequence 32184
Current log# 6 seq# 32184 mem# 0: E:\APP\ADMINISTRATOR\ORADATA\SN67\REDO06.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
[4568] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:35833 end:36535 diff:702 (7 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Thu Ju
...全文
1137 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
sxq129601 2017-06-12
  • 打赏
  • 举报
回复
你这解决的方法,根本和自动关闭没半毛关系,Shutting down instance (immediate)是正常的关闭,看看有没有任务计划之类的或者其他人手工关掉了
xozhangyi 2017-06-10
  • 打赏
  • 举报
回复
问题已经解决,但并没有进行任何修改。 操作如下: 1. 快速startup数据库; 2. offline除Oracle系统表空间的其他应用程序表空间; 3. 逐个开启应用程序表空间; 4. 数据库服务正常,没有宕机,重启Oracle服务器后一切正常; 真是奇葩事件。。。。。
xozhangyi 2017-06-05
  • 打赏
  • 举报
回复
非常感谢,我日志贴的不全,可能没有贴到问题关键。 附件是整个alter日志,应该是5月29号凌晨应用无法登陆了。 链接:http://pan.baidu.com/s/1dFkr5rb 密码:lecm 操作系统出来Oracle服务关闭有一个报错,就再没什么别的报错了。。
jdsnhan 2017-06-05
  • 打赏
  • 举报
回复
Fri Jun 02 16:12:19 2017 Shutting down instance (immediate) 这是一种正常关闭啊,看看OS层有没有什么设置,或者看看windows的服务及日志有没有什么log
 针对数据库的启动和关闭、控制文件与数据库初始化、参数及参数文件、数据字典、内存管理、Buffer Cache与Shared Pool原理、重做、回滚与撤销、等待事件、性能诊断与SQL优化等几大Oracle热点主题,本书从基础知识入手,深入研究相关技术,并结合性能调整及丰富的诊断案例,力图将Oracle知识全面、系统、深入地展现给读者。   本书给出了大量取自实际工作现场的实例,在分析实例的过程中,兼顾深度与广度,不仅对实际问题的现象、产生原因和相关的原理进行了深入浅出的讲解,更主要的是,结合实际应用环境,提供了一系列解决问题的思路和方法,包括详细的操作步骤,具有很强的实战性和可操作性,适用于具备一定数据库基础、打算深入学习Oracle技术的数据库从业人员,尤其适用于入门、进阶以及希望深入研究Oracle技术的数据库管理人员。 第1章 数据库的启动和关闭 1 1.1 数据库的启动 1 1.1.1 启动数据库到NOMOUNT状态的过程 2 1.1.2 启动数据库到MOUNT状态 18 1.1.3 启动数据库OPEN阶段 26 1.2 数据库的访问 37 1.2.1 客户端的TNSNAMES.ORA文件配置 37 1.2.2 服务器端的监听器文件listener.ora配置 39 1.2.3 通过不同服务器名对数据库的访问 41 1.2.4 动态监听器注册服务 42 1.3 数据库的关闭 46 1.3.1 数据库关闭的步骤 46 1.3.2 几种关闭方式的对比 48 第2章 控制文件与数据库初始化 51 2.1 控制文件的内容 51 2.2 SCN 53 2.2.1 SCN的定义 53 2.2.2 SCN的获取方式 53 2.2.3 SCN的进一步说明 54 2.3 检查点(Checkpoint) 57 2.3.1 检查点(Checkpoint)的工作原理 57 2.3.2 常规检查点与增量检查点 59 2.3.3 LOG_CHECKPOINT_TO_ALERT参数 63 2.3.4 控制文件与数据文件头信息 64 2.3.5 数据库的启动验证 66 2.3.6 使用备份的控制文件 70 2.3.7 FAST_START_MTTR_TARGET 71 2.3.8 关于检查点执行的案例 74 2.3.9 Oracle 10g自动检查点调整 75 2.3.10 检查点信息及恢复起点 78 2.3.11 正常关闭数据库的状况 78 2.3.12 数据库异常关闭的情况 80 2.3.13 数据库并行恢复案例一则 82 2.3.14 判断一个死事务的恢复进度 85 2.4 数据库的初始化 86 2.4.1 bootstrap$及数据库初始化过程 86 2.4.2 bootstrap$的定位 88 2.4.3 Oracle中独一无二的Cache对象 89 2.4.4 Oracle数据库的引导 91 2.4.5 系统对象与bootstrap$ 92 2.4.6 bootstrap$的重要性 94 2.4.7 BBED工具的简要介绍 95 2.4.8 坏块的处理与恢复 97 第3章 参数及参数文件 103 3.1 初始化参数的分类 103 3.1.1 推导参数(Derived Parameters) 103 3.1.2 操作系统依赖参数 104 3.1.3 可变参数 104 3.1.4 初始化参数的获取 105 3.2 参数文件 107 3.2.1 PFILE和SPFILE 108 3.2.2 获取参数的视图 110 3.2.3 SPFILE的创建 111 3.2.4 SPFILE的搜索顺序 112 3.2.5 使用PFILE/SPFILE启动数据库 112 3.2.6 修改参数 113 3.2.7 解决SPFILE参数修改错误 118 3.2.8 重置SPFILE中设置的参数 120 3.2.9 判断是否使用了SPFILE 120 3.2.10 SPFILE的备份与恢复 121 3.2.11 Oracle 11g参数文件恢复 127 3.2.12 如何设置Events事件 128 3.2.13 导出SPFILE文件 129 3.3 诊断案例之一:参数文件 131 3.3.1 登录系统检查告警日志文件 131 3.3.2 尝试重新启动数据库 132 3.3.3 检查数据文件 132 3.3.4 MOUNT数据库,检查系统参数 133 3.3.5 检查参数文件 133 3.3.6 再次检查alert文件 134 3.3.7 修正PFILE 135 3.3.8 启动数据库 135 3.4 诊断案例之二:RAC环境参数文件 135 3.4.1 数据库资源异常 135 3.4.2 问题的发现 136 3.4.3 参数文件问题的解决 137 第4
vf6.0,要考二级没系统的下哈 Microsoft Visual FoxPro 6.0 for Windows 的常见问题 这些是有关 Microsoft Visual FoxPro 最常见的问题。在您求助 Microsoft 产品支持服务之前,请先查阅这张列表。 若想打印这些附注,请从“文件”菜单中选择“打印”命令。此文档分为以下四部分: --------------------------------------------------------------------- 部分 1. 技术支持与市场 部分 2. Visual FoxPro 6.0 新增功能 部分 3. 从其他版本的 FoxPro 和 Visual FoxPro 中移植 部分 4. Visual FoxPro 常见问题 --------------------------------------------------------------------- 部分 1. 技术支持与市场 问题 1-1: 从何处可以获得产品的更新版本? 答案: 在 Visual FoxPro 的 Web 站点上即可获得产品的更新信息,其中包括有关 Service Pack 和更新的示例、向导及其他代码的信息,该站点的网址为: www.microsoft.com/vfoxpro 请定期查看该网站,以便下载产品的最新版本。 问题 1-2: 从何处可以得到有关 Visual FoxPro 的详细资料? 答案: 通过 Microsoft Visual FoxPro Web 站点是随时获得各种最新产品发布信息的最佳途径。在此站点上不仅有新的产品公告,而且还提供了产品的更新信息、技术文章、白皮书、专业开发人员设计的优秀示例、会议公告、以及与其他许多 FoxPro web 站点的各种链接。 问题 1-3: 如何获得技术支持,以及如何报告软件错误? 答案: Microsoft Visual FoxPro Web 站点已经链接到了多种联机支持选项,其中包括覆盖面广阔的有关所有产品 Microsoft Knowledge Base(Microsoft 知识库)。您还可以阅读一份有关常见问题的清单。除联机支持之外,还可以直接通过电话获得技术支持。“帮助”菜单中的选项可列出技术支持的电话号码。这些电话号码也可用于报告产品中的错误。 问题 1-4. 什么是 Knowledge Base?如何使用它? 答案: Knowledge Base 是内容广泛的论文集,覆盖了如何使用产品的各种特性、已知的软件错误及其解决方案或回避的方法、以及其他有助于使用各种 Microsoft 产品的有用信息。通过以下站点可访问整个 Knowledge Base: support.microsoft.com 问题 1-5: 是否会有 Visual FoxPro 6.0a? 答案: Microsoft 公司一向承诺为用户提供高质量的产品。如果确实需要,我们将提供 Visual FoxPro 6.0 的错误修订版。但是,修订版不会使用 6.0a 版的形式。Visual FoxPro 6.0 中任何错误的修正都将包含在 Visual Studio Service Pack 中。同时还会在 Visual FoxPro 的 www.microsoft.com/vfoxpro 或 Visual Studio 的www.microsoft.com/vstudio 的 Web 站点上发布修订公告。 问题 1-6: Microsoft 公司为应用程序的开发提供了一些优秀的解决方案。怎样才能知道应该向客户推荐和使用哪种产品? 答案: 在选择适用某项任务的产品时,需要考虑多方面的因素。Microsoft Visual FoxPro web 站点上有一份优秀的策略背景论文,它比较了 Visual FoxPro、Visual Basic、SQL Server 和 Access 等 Microsoft 产品之间的不同。 问题 1-7: 哪里可以找到 Visual FoxPro 的使用示例? 答案: Visual FoxPro 6.0 产品中带有丰富的示例,其中有一些是针对 6.0 版特有功能的新示例。与 Visual FoxPro 以前的版本不同,这些示例将与所有 Visual Studio 示例安装在一起。您必须运行 MSDN Library 的“自定义”安装来安装这些示例。在 Visual FoxPro 中可使用新的 HOME(2) 函数方便地找到已安装示例的位置。 除了产品中所自带的示例外,Microsoft Visual FoxPro web 站点还将经常提供新的示例。

17,377

社区成员

发帖
与我相关
我的任务
社区描述
Oracle 基础和管理
社区管理员
  • 基础和管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧