Author: mac

SQL> select file_id,file_name from dba_data_files where tablespace_name=’SYSAUX’; FILE_ID ———- FILE_NAME ——————————————————————————————————————————————– 2 /s01/oradata/FIXIT/datafile/o1_mf_sysaux_85wkhmrk_.dbf SQL> alter database datafile 2 offline; Database altered.   假设这里datafile 2即SYSAUX所有的数据文件都丢失了 且没有任何备份，此时我们无法利用任何备份还原该表空间 但是SYSAUX表空间却是数据库必要的系统表空间之一，存放了 AWR等重要数据和其他一些组件的辅助数据     SQL> exec dbms_workload_repository.create_snapshot; BEGIN dbms_workload_repository.create_snapshot; END; * ERROR at line 1: ORA-13509: error encountered during updates to a AWR table ORA-00376: file ORA-00376: file 2 cannot…

据悉Oracle Database 12.1 (12c)这个未来版本的Beta版已经开始在Oracle内部大规模测试，见下图:     12c的官方文档已经在Oracle内部网络可访问，包括Concepts、Reference和SQL Tuning Guide等，但似乎还没有12c 12.1 New Feature的文档。 以下为12.1 12c使用DBUA图形化工具升级数据库的界面，可以看到图形化界面的美学风格和11gR2没有太大的差别。     这些文档在外部尚不能访问，但是12c Release 1 (12.1) Beta的文档主页已经建立:

默认EM Grid/Cloud Control的HTTPS协议登陆端口是7799，而HTTP协议的端口是7788，但是请注意默认不会启用HTTP协议登陆EM。准确地说Oracle更prefer 安全的HTTPS协议。 如果你使用HTTP登陆EM，如http://hostname:7788/em时可能遇到403错误(HTTP 403 Forbidden)，这是由于默认不启用HTTP协议登陆EM。 该问题可以通过emctl secure unlock -console解锁console，并重启OMS来解决： Enterprise Manager Grid Control – Version: 11.1.0.1 and later [Release: 11.1 and later ] Information in this document applies to any platform. Symptoms Trying to access the 11g Grid Console using the URL: http://omsmachine.domain:7788/em resulted in the error: The website declined to show this…

ORA-00054 资源正忙 “resource busy and acquire with NOWAIT specified”错误 [oracle@mlab2 data]$ oerr ora 00054 00054, 00000, “resource busy and acquire with NOWAIT specified or timeout expired” // *Cause: Interested resource is busy. // *Action: Retry if necessary or increase timeout.   引起该错误的常见原因是： 所需要的资源正忙或者参数DDL_LOCK_TIMEOUT(11g)指定的DDL锁超时指标被达到，注意在11g之前默认情况下DDL语句以NOWAIT形式出现 对于该错误的建议是 稍后重试SQL命令语句，推荐是在业务空闲时期执行，或者指定更大的DD_LOCK_TIMEOUT，或者不要使用显示的NOWAIT子句   关于该ORA-00054错误的详细说明： 在绝大多数情况下ORA-00054都是最常见不过的报错信息，常在SQL语句被其他用户的工作阻塞时出现，该被阻塞的SQL命令存在2种可能： 在语句中指定了”NOWAIT”子句，因此该语句将不被阻塞等待，而直接报错即ORA-00054错误 语句本身是DDL，在11g之前或者DDL_LOCK_TIMEOUT=0，该DDL语句直接返回ORA-54错误 简而言之 DDL或 SELECT .. FOR…

OEL 5.7 + ORACLE RAC 11.2.0.2 在运行过程中系统监控台出现journal commit I/O error的信息: SQL> oradebug Message from syslogd@ at Fri Oct 14 21:17:08 2011 … vrh1 kernel: journal commit I/O error [root@vrh1 ~]# tail /var/log/messages Oct 14 21:02:49 vrh1 kernel: [Oracle OKS] ODLM hash size 62500 Oct 14 21:02:49 vrh1 kernel: OKSK-00004: Module load succeeded. Build information: (LOW…

有网友在itpub上反应11g中查看EM dbconsole显示数据文件的使用量为负数,如图：     实际上导致(EM ( EM Home page -> Administration Tab -> Storage -> Datafiles ))显示负的使用量的Bug在11g和10g中均存在，这里将这些bug列出来以供参考:   10g Enterprise Manager Shows Negative Utilisation For An Oracle Datafile. Applies to: Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.3 This problem can occur on any platform. Symptoms EM ( EM Home page -> Administration…

resmgr:cpu quantum是Resource Manager特性导致的等待事件，理论上只有版本10g以后才可能出现，同时应当仅在resource manager plan被激活的时间窗口中发生该等待事件。 该等待事件存在的意义是当resource manager控制CPU调度时，需要控制对应进程暂时不使用CPU而进程到内部运行队列中，以保证该进程对应的consumer group(消费组)没有消耗比指定resource manager指令更多的CPU。 此时session就会以”resmgr:cpu quantum”的名义等待在内部运行队列中，wait一段时间以减少对CPU的争用，直到再次获得CPU时该等待事件结束。         需要注意的是虽然国内的绝大多数数据库都不太可能去设置resource plan激活某种资源计划，但是10g开始默认的gather_stats_job自动收集统计信息作业会在每个工作日的晚上22:00-06:00和周六、周日全天打开default_maintance_windows该维护窗口会默认打开一个Oracle预定义的资源计划，在这个窗口中服务进程仍可能进入resmgr:cpu quantum等待事件。 合理的resmgr:cpu quantum是为了实现cpu control的必要代价，但是存在一些BUG可能导致服务进程因为resmgr:cpu quantum而HANG住，并一直等待该事件，这些BUG主要发生在10g的10.2.0.5之前。   AWR TOP 5 EVENT: Event Waits Time(s) (ms) time Wait Class ———————————– ——— —— —— ———- resmgr:cpu quantum 1,193,863 96,152 81 67.0 Scheduler enq: HW – contention 11,789 13,172 1117 9.2 Configurat…

数据库资源管理器通过控制数据库内部的执行调度来控制资源在各个会话之间的分布。通过控制所要运行的会话以及会话运行的时间长度，数据库资源管理器可以确保资源分布与计划指令相匹配，因此也符合业务目标。   请注意，oracle resource manager对CPU的限制粒度为消费组(consumer group)， 无法细化控制消费组内个别进程消耗CPU的比例，只要不超出该消费组的CPU限制，消费组内的单个或多个进程的CPU使用不受限制。     10g中Resource Manager资源管理器可以控制的资源种类：   Oracle进程的CPU使用率 并行度(Parallel) UNDO数量 SQL语句操作执行时间(Execute Time) 会话空闲时间(Idle Time) 活跃会话(session)数   以下会话属性可以用来作为映射规则的条件，换而言之Resource Manager仅可以通过下列会话属性来区分session的消费组：   2．      介绍Resource Manager如何控制CPU   有两种方法可以通过CPU_MTH 参数指定CPU 使用率：   EMPHASIS，这是默认方法，用于多级计划，它以百分比形式指定CPU 如何在使用者组之间分布。     EMPHASIS CPU 分配方法确定在资源计划中对不同使用者组中的会话的重视程度。CPU 占用率的分配级别为从1 到8，级别1 的优先级最高。百分比指定如何将CPU 资源分配 给每一级中的各个使用者组。   以下规则适用于EMPHASIS 资源分配方法：   CPU 资源在给定级别按指定的百分比分配。为资源使用者组指定的CPU 百分比是该 使用者组在给定级别可以使用的最大值。 给定级别上没有使用的使用者资源可供下一级别的使用者组使用。例如，如果级别1 的使用者组只使用了60% 的可用资源，则其余的40% 可供级别2 的使用者组使用。 任何给定级别的百分比总和必须小于等于100。 对于没有明确指定计划指令的所有级别，其所有子计划或使用者组的默认资源是0%。 EMPHASIS 资源分配方法避免了资源缺乏问题，该问题导致优先级较低的使用者没 有运行的机会。     EM图形界面下使用EMPHASIS 资源分配方法     SQLPLUS命令行下使用EMPHASIS 资源分配方法   BEGIN…

  本文永久地址：https://www.askmac.cn/archives/oracle-dba-%E6%93%8D%E4%BD%9C%E6%89%8B%E5%86%8C-handbook.html Oracle DBA 操作手册 Handbook    系统规划   系统规划指南 数据库容量计算与系统的并发用户数及每秒交易量相关，也与交易类型相关，如 增、插、删、改、查询等等。例如目前资源库的数据量大约在 5TB 左右，以年增量 30% 计算， 可预估需要处理的数据量在 5TB 到 10TB 之间。 根据我们的经验，可以从系统的 TPMC 的估算得出粗略的 CPU 个数及内存需求。 为了比较科学的得到某省集中运行 BOSS1.5 系统所需资源配置情况，我们制定了两种 不同的方法来进行，然后将两种推算的结果进行对比，从而得出某省集中运行 BOSS1.5 系统所需资源，进而给出对资源的分配方案。 第一种方法是比较法。这种方法是根据我们得到的其他省份同类型客户运行 BOSS1.5 系统时的资源占用情况，再对比 2 个省份的业务数据，以线性方法来推算。 第二种方法用标准测算 TPMC 值的方法，测算某省客户每笔业务交易所需要的 TPMC 值，从而推算出集中运行 BOSS1.5 系统所需的资源。     比较法推算主机性能需求   BOSS 系统作为客户最主要和最重要的应用系统，是其他所有应用系统的基础数据 来源和应用基础。在所有的应用系统里面，本系统负荷最重，对设备需求最高，同时 对时效性和安全性以及数据完整性的要求也最高，因此，本系统要求配备独立的主机 并配置双机热备系统，同时为保证系统数据的安全性和完整性，需对存储设备按照 RAID0＋1  的标准进行配备。…

节前帮网友打开了一套断电后无法正常启动的10.2.0.1数据库，该库使用非归档模式且没有任何备份。 主机断电后，该网友尝试重启数据库实例，但是遇到了ORA-00600:[kccpb_sanity_check_2]内部错误:   如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   SQL> select status from v$instance; STATUS ———— STARTED SQL> SQL> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 2147483648 bytes Fixed Size 1220432 bytes Variable Size 486539440 bytes Database Buffers 1644167168…