Author: mac
-
Oracle 在RAC 数据库的datapatch失败,显示错误:”PLS-00201 , ORA-01109 & ORA-01219″
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] ORA-01109 oerr ora 1109 01109, 00000, “database not open” // *Cause: A command was attempted that requires the database to be open. // *Action: Open the database and try the command again ORA-01219 [oracle@ocm_test01 dul1]$ oerr ora 1219 01219, 00000, “database not open: queries allowed on fixed tables/views…
-
Oracle链接到只读Standby 显示 “ORA-01089: Immediate Shutdown In Progress “
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] 适用于: Oracle Database – Enterprise Edition – 版本11.2.0.3 到11.2.0.3 [Release 11.2] 本文信息适用于任何平台。 ***13-Jul-2015检测相关性*** 目标 这是11.2.0.3 Active Data Guard Physical Standby 简单的SQL*PLUS 连接到该物理备用数据库能运作。 通过dblink简单查询该只读备用数据库失败,显示以下错误, SQL> select count(*) from SCOTT.EMP@TEST * Error at line 1 ORA-01089: immediate shutdown in progress – no operations are permitted ORA-02063: preceding line from…
-
Oracle Bug 13724193 – ORA-1089 over database link involving transitioned primary
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] ORA-01089 oerr ora 1089 01089, 00000, “immediate shutdown in progress – no operations are permitted” // *Cause: The SHUTDOWN IMMEDIATE command was used to shut down // a running ORACLE instance, so your operations have been // terminated. // *Action: Wait for the instance to be restarted,…
-
Oracle 在分区表的收缩和拆分后生成Bug 7313847 – OERI[ktecgetsh-inc]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] 在分区表的收缩和拆分后Bug 7313847 OERI[ktecgetsh-inc] 本文介绍bug 7313847的简要概述。 内容最后更新于:28-JUN-2013 点击 这里 获取以下各部分的详情。 影响: 产品 (组件) Oracle Server (Rdbms) 认为受影响的版本范围 12.1以下版本 确认为受影响的版本 11.2.0.1 11.1.0.7 10.2.0.5 10.2.0.4 受影响的平台 通用 (全部/大部分受影响的平台) 被修正: 问题被修正于 12.1.0.1 (Base Release) 11.2.0.2 (Server Patch Set) 症状: 相关: Error May Occur Internal Error May Occur (ORA-600) ora-10632 ORA-600 [ktecgetsh-inc] Partitioned Tables…
-
Oracle ORA-600: [KTECGETSH-INC], [1]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] 适用于: Oracle Database – Enterprise Edition – 版本10.2.0.4 到11.2.0.1.0 [Release 10.2 to 11.2] 本文信息适用于任何平台。 *** 29-May-2013检查相关性*** 症状 在alert.log中遇到以下错误: ORA-00600: internal error code, arguments: [ktecgetsh-inc] 跟踪文件显示了问题出现在分区表的INSERT语句。 Call Stack调用堆栈 ktecgetsh <- ktecgshx <- ktspisc <- ktspgsp_cbk1 <- ktspgsp_cbk <- kdtgsp <- kdtgsph <- kdtgrs <- kdtInsRow <- insrow <-…
-
Oracle 数据库的stuck recovery ORA-00600[3020]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] 适用于: Enterprise Manager for Oracle Database – 版本10.1.0.2 到 12.1.0.2.0 [Release 10.1 to 12.1] Oracle Database – Enterprise Edition – 版本 9.0.1.4 到 12.1.0.2 [Release 9.0.1 to 12.1] Oracle Database – Personal Edition – 版本 9.2.0.1 到12.1.0.2 [Release 9.2 to 12.1] 本文信息适用于任何平台。 *** 16-Apr-2014检查相关性*** 症状 在做恢复时,恢复过程可能会失败,生成ORA-600 [3020]错误信息…
-
Oracle 解决在恢复时生成的ORA-600[3020]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected] 适用于: Oracle Database – Enterprise Edition – 版本 9.2.0.1 到 11.2.0.2 [Release 9.2 to 11.2] Oracle Database – Enterprise Edition – 版本 11.2.0.4到 11.2.0.4 [Release 11.2] 本文信息适用于任何平台。 症状 恢复会话失败: SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [13204236], [1],…
-
OGG 报错信息汇总OGG_Error_Messages
OGG-00001: Execution cannot continue – Program Terminating Cause: This is a generic message that indicates a process failure. Action: Look for other messages in the process report and error log that provide more context for this failure. If you cannot determine and resolve the problem, contact Oracle Support. OGG-00002: Missing directory name Cause: The…
-
Oracle Clusterware 11g Release 2集群件clusterware详解
本文永久地址:https://www.askmac.cn/archives/oracle-clusterware-11-2.html 到Oracle数据库11g第2版(11.2)的过渡中,Oracle集群做了大量的改变,完全重新设计了CRSD,引进了“本地CRS”(OHASD)和紧密集成的代理层更换RACK层。新的功能,如Grid Naming Service,即插即用,集群时间同步服务和Grid IPC。集群同步服务(CSS)可能是影响最小的变化,但它提供支持新功能的功能,以及添加了新的功能,如支持IPMI。 有了这个技术文件,我们想借此机会,提供所有的我们已经积累了多年的11.2的发展技术,并将其转发给那些刚刚开始学习Oracle 11.2集群的人。本文提供了总体概述,以及相关的诊断和调试的详细信息。 由于这是Oracle集群诊断文章的第一版本,而不是11.2集群覆盖的全部详细信息。如果你觉得你可以对本文档提供帮助与修改,请告诉我们。 1. Oracle 集群架构 这节将介绍Oracle集群的主要守护进程 1.1 守护进程(Daemons)和代理(agent)概述 下图是关于Oracle集群11.2版本所使用的守护进程,资源和代理的高度概括。 11.2版本和之前的版本的第一个大的区别就是OHASD守护进程,替代了所有在11.2之前版本里的初始化脚本。 Oracle高可用服务守护进程 (OHASD) Oracle集群由两个独立的堆栈组成。上层Cluster Ready Services守护进程(CRSD)堆栈和下层Oracle High Availability Services守护进程(ohasd)堆栈。这两个堆栈有促进集群操作几个进程。下面的章节将详细介绍这些内容。 OHASD是启动一个节点的所有其他后台程序的守护进程。OHASD将替换所有存在于11.2之前版本的初始化脚本。 OHASD入口点是/etc/inittab文件,其执行/etc/init.d/ohasd和/etc/init.d/init.ohasd。/etc/init.d/ohasd脚本是包含开始和停止操作的RC脚本。/etc/init.d/init.ohasd脚本是OHASD框架控制脚本将生成Grid_home/bin/ ohasd.bin可执行文件。 集群控制文件位于/ etc/ ORACLE / scls_scr/<hostname>/root(这是Linux的位置),并维护CRSCTL;换句话说,一个“crsctl enable / disable crs”命令将更新该目录中的文件。 如: [root@rac1 root]# ls /etc/oracle/scls_scr/rac1/root crsstart ohasdrun ohasdstr # crsctl enable -h…
-
Oracle 数据整合架构探讨
服务器整合以及数据整合 广义来说,数据整合就是服务器整合的架构之一。在服务器整合之中,有很多种架构。一般而言,应该以理论整合、地址整合、物理整合为焦点来讨论,所以这次不会说到应用整合。并且,数据整合是服务器整合的架构之一,但本文并不打算将数据整合特殊化,所以我们故意将数据整合以及服务器整合来分开说明。没有特别含义的情况下,“服务器整合”意味着服务器理论整合、服务器为止整合、服务器位置整合、然后数据整合也以为和需要将数据库进行再次架构、变更的数据的整合。 在此,为了明确服务器整合以及数据整合所需要的理由、环境的变化以及问题点,我们将说明导入了分散配置的系统的背景。 导入分散配置服务器的系统的背景是上世纪90年代,提倡技术的开源化的时代。伴随着开源技术的渗透,以PC服务器的使用为中心的终端Computing得到了增加。这样的架构是一个,对于终端用户所需要的信息,用必要的形式,在需要时,可以使用的方法。 并且,上世纪90年代的网络与其他因素相比较(服务器、软件、管理者的人工费等),价格稍高,所以系统都被尽量设计成不经过网络而得到数据的形式。另外,因为服务器自身的处理能力也是有限度的,一般而言系统架构都是在Downsizing之名之下,之下分散处理。 接下来,我想说明Downsizing、分散,在开源的世界中,环境发生了怎样的变换。 上世纪90年代使人们都选择分散配置系统的IT环境,如今也发生了翻天覆地的变换。首先是飞跃性的技术进步,服务器性能得到了飞跃性地提高,网络带宽也得到了扩展以及成本也得到了降低。服务器的能力单纯就CPU clock数来说,提高了几十倍到几百倍,而网络带宽的性能则提高了几百倍到几千倍。因此,至今不得不分散就无法处理的业务,都可以聚集到极少数几个服务器中来执行处理。 另外,在如今IT泡沫破灭的当今的各大企业中,正在积极推行提高资源利用效率、减少成本。比如,如利用Outsourcing来扩张自己的核心竞争力一样,经常可以看到有尽量减少核心业务以外所花费的时间来提高竞争力的情况。伴随着这样的变化,服务器以及系统的管理业务等,由这方面的专家,信息系统部,外包商来集中执行。用户为了更高效执行业务,利用系统,渐渐将其移动到不执行这些运用以及管理的架构中。 由这些背景,与环境的变换,我们就明确问题是什么,要解决什么。我们可以想到有以下四种有问题的要素。 a.TCO b.系统可信性 c.安全水平 d.数据质量 a. TCO 相对于硬件的性能提高以及成本性能的提高,系统维护、管理业务中所必需的人工费却并没有下降。即使是在现在这个不景气的环境下,人工费的价格刚性还是较高,特别在日本人工费的高昂都被当做一个社会问题来研究了。换言之,要就这样一直维持进行了分散配置的架构的情况下,即使硬件、软件、网络的成本都下降了,在使用以及管理时所花费的成本也并不会下降。当之前分散配置是主流时,减少网络成本是个重要的课题,而现在最重要的是减少人工费。换言之,减少人工费对减少成本产生的效果更好。那么要减少人工费的话,就需要减少将会成为使用、管理对象的服务器数、种类以及对象软件的种类。 另外,在将服务器于每个用户部门中进行分散配置的系统中,执行使用以及管理的就不是信息系统部门,而是用户部门了。备份工作等使用工作以及面向故障的一次性对应,现在都变成由用户部门的用户来执行了。由此,使用管理处理就会从信息系统部门移动到用户部门,后果就是用户本来应该花费在执行的最优先业务上的时间,变成花在了使用、管理上了,造成资源利用效率降低。虽然通过将服务器从用户部门移动到信息系统部门,或者系统运用管理员配置到各个用户部门中,有望解决这个问题,但实际上要在各个用户部门中分配管理员的费用都是非常高的。 b.系统可信性 在进行分散配置开始时,我想通过分散配置多个服务器,从而提高系统整体的可信度,但实际上,在每个服务器的可用性都较低的情况下,我发现系统整体的可信性并不会继续提高。特别是实时指向较高,在流程都被明确地定义,每个业务进程的关联都得到加强的先到业务系统中,可能因为一个系统停止,导致全部的流程也停止。另外,被分散配置的服务器使用比较便宜的PC服务器的情况较多,无法取得足够的冗长结构从而无法提高可信性。要解决这个问题,就应该使用具有充分可信性的服务器,但要将现有的所有服务器全部切换成高可信性服务器的话,可能需要花费大量成本。并且考虑到使用管理多台服务器的成本的话,集中配置Fault-tolerant machine, cluster system以及大规模SMP machine来使用反而可以减少总体成本,并且可以提高整体可信性。特别是对于cluster system需要大量费用的情况,效果很好。并且,通过与便宜的存储组合,构成服务器的情况下,就无法对发生故障的磁盘进行热插拔,会出现无法取得由于冗长镜像所进行的高速备份的限制。通过使用SAN、NAS Storage,可以提高所有服务器的可信性。 在用各用户部门执行用户管理的情况下,特别是备份、恢复相关的应用水平可能发生错误。服务水平、复原顺序、系统复原优先顺序、备份保持期间,根据各个部门不同会有差异,根据发生故障的系统不同,可能会使得系统整体的MTTR产生变动,从故障发生时的故障转移地址的能力预测是很难的等系统使用的观点来看的话,不确定因素太多,风险也太大。解决方法有,对系统整体进行备份,恢复方案等,由信息系统部指定多的,将各部门管理这作为对象来训练的方案,但对于必须优先业务的用户部门的资源来说,这对成本的负担太过沉重,所以在没有如方案所述取得备份的情况下,就无法使用通常的恢复顺序,导致故障长期化。引起,要减少服务器的聚集数,从remote进行备份、恢复也是可行的。 c. 安全水平 在用户部门中执行服务器管理时,有在安全性较低的环境中使用/管理的情况。将业务处理中成为关键的服务器放在安全水平较低的环境中不管的话,这不仅可能危害到整个部门,甚至可能危害到全公司。如果是储存对于那个部分相当关键的数据的情况下,如果产生故障,就应该立即停止业务。并且,部门服务器连接公共网络的情况较多,因为网络的分割,对于网上数据的保护就不够充分,可能造成数据流出。如果在设置地点不安排专用的空间的话,就可能导致不相干的人也可以访问数据,并且无法对抗火灾、地震。要防止数据泄露,在发生故障时也能继续业务,就需要维持充分的安全性。聚集服务器,补充设置地点的设备,导入安全管理软件,重新架构网络。 d.数据质量 在分散配置系统中,用户部门会用架构业务上必要的处理的单位来架构。因此,对于全公司的必须得到统一管理的数据,各自系统就可以保持独自的形态来构筑系统。因此,分散系统的系统架构中,就会发生被称为Information Island的数据服务器。系统之间无法协作,或者说因为不够充分,会经常有数据重复等数据非一致的状态。比如,订购业务系统中的顾客数据与支持业务系统中顾客数据的重复与不一致。换言之,我们可以说这就是数据质量低下。另外,数据重复并被保持是指,出现了白白增加储存数据的存储设备、内存等浪费性的IT投资。在系统之间,对顾客的数据进行维护,但维护的时间不太准确的情况下,就会破坏数据的一致性。最近的趋势都是追求实时性,请大家尽可能回避这样的情况,可能的话,请在所有系统中都保持数据的一贯性。 以上整理如下表1.1所示。 CTO 信赖性 安全性 数据品质 问题 管理者增加 服务器很多 配置地址多样 SW种类 HW种类 ->管理成本增加 不准备备份 不充分的冗长性 对整个系统的冲击…