今天在启动数据库时遭遇到 $ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Tue Jul 16 21:28:03 2013 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to an idle instance. SQL> startup nomount; ORA-01078: failure in processing sys
innodb文件损坏报错如下: 2018-09-03T09:52:43.486363Z 0 [ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=0, page number=50345472], should be [page id: space=0, page number=408] 2018-09-03T09:52:43.486498Z 0 [ERROR] InnoDB: D
实验前提:已经做好备份. SQL> col file_name for a50select file_id,file_name from dba_data_files; FILE_ID FILE_NAME---------- --------------------------------------------------4 /home/oracle/app/oradata/orcl/users01.dbf2 /home/oracle/app/oradata/orcl/sysaux01.dbf
一.问题发现 命令行进入数据库实例手动给某张表进行alter操作,发现如下报错. mysql> use xx_xxx; No connection. Trying to reconnect... Connection Current database: *** NONE *** Reading table information for completion of table and column names You can turn off this feature to get a quic
一.概述 本文将给大家介绍oracle各类文件损坏的现象和应对策略,请注意所有的恢复都是基于有备份的情况,所以请开启数据库的日常备份.文章将从以下文件展开 a. 密码文件 b. 参数文件 c. 控制文件 d. 数据文件(分普通表空间数据文件,其它表空间数据文件如system.sysaux.undo) e. 日志文件(分current.active.inactive) 在正式实验之前,我先问一个问题,上面这些文件,哪个损坏最致命? 二.环境准备 本实验在oracle 11G归档模式下进行,实验前先