sqlplus 组件意外被破坏恢复测试

sqlplus 组件意外被破坏恢复

在执行 sqlplus / as sysdba 命令后没啥反应,有点奇诡。。。

[[email protected] bin]#sqlplus / as sysdba

[[email protected] bin]# ls -trl

...

-rwxr-x--x 1 oracle oinstall         0 Dec  9 15:52 sqlplus  -------这个文件居然被写空了

...

恢复测试:

从oracle 11201拷贝一个sqlplus 过来,修改完权限后进行测试:

[[email protected] bin]# ls -trl

-rwxr-x--x 1 oracle oinstall      9197 Dec 24 10:26 sqlplus

[[email protected] ~]$ sqlplus / as sysdba

SP2-1503: Unable to initialize Oracle call interface

SP2-0152: ORACLE may not be functioning properly

[[email protected] ~]$

关于上述报错官方解释:

01503,0, "Unable to initialize Oracle call interface\n"

// *Cause:  Indicates a library used by SQL*Plus to communicate with

//          the database failed to initialize correctly.

// *Action: Check that the Oracle environment or registry entries are

//          consistent and correct.  If using the SQL*Plus Instant Client

//          make sure the SQL*Plus and Oracle libraries are from the

//          same release. Make sure you have read access to the libraries.

00152,0, "ORACLE may not be functioning properly\n"

// *Cause:  Unable to initialize a session to the Oracle instance.

// *Action: Make a note of the message and the number, then contact

//          the Database Administrator.

从报错的信息来看主要是sqlplus 无法调用正常的lib 库文件,因而无法和/bin/目录下的oracle(rdbms)进行通信;

那么如果是从同平台同版本的oracle 数据库中拷贝一个sqlplus 组件过来,没准就能用的?

[[email protected] bin]# ls -trl

...

-rwxr-x--x 1 oracle oinstall      7725 Dec 24 10:29 sqlplus

再次测试:

[[email protected] bin]$ !sql

sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Wed Dec 24 10:30:18 2014

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area  583008256 bytes

Fixed Size                  2074440 bytes

Variable Size             436209848 bytes

Database Buffers          138412032 bytes

Redo Buffers                6311936 bytes

Database mounted.   --------》数据库可以正常启动

Database opened.

来点暴力的,但是感觉和数据库没啥关系啊?

SQL> startup force

ORACLE instance started.

Total System Global Area  583008256 bytes

Fixed Size                  2074440 bytes

Variable Size             440404152 bytes

Database Buffers          134217728 bytes

Redo Buffers                6311936 bytes

Database mounted.

Database opened.

SQL> show parameter dump

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

background_core_dump                 string      partial

background_dump_dest                 string      /oracle/admin/lixora/bdump

core_dump_dest                       string      /oracle/admin/lixora/cdump

max_dump_file_size                   string      1024

shadow_core_dump                     string      partial

user_dump_dest                       string      /oracle/admin/lixora/udump

SQL> select open_mode from v$database;

OPEN_MODE

----------

READ WRITE

SQL> select * from dual;

D

-

X

一切ok,这里冒出一个想法,如果 rman or dbca or netca 。。。。意外损坏,是不是也可以按上方法来替换解决呢?找机会测下

时间: 2024-10-24 20:31:47

sqlplus 组件意外被破坏恢复测试的相关文章

ORACLE数据库文件丢失后的恢复测试

一.测试环境 数据库版本是11GR2,在做完一份完全备份之后,关机,做一份快照,每一次开机之后都执行数次alter system switch logfile以产生归档日志. 之后的测试都是基于这么一个完全备份来恢复. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F'; backup incremental level 0 format '/backup/%T_%f' database; 二.

RMAN 0级恢复测试---RAC+ASM恢复到单机

最近做了一次RMAN 0 级恢复测试,测试模拟了生产数据库发生灾难性故障,只剩下rman全备份的备份片,利用备份的spfile.控制文件.数据文件.归档日志恢复数据的过程. 首先说一下环境,网上很多文章都是互相粘贴,并不一定适用于你的测试环境.我这次测试的生产环境是2个节点的RAC,存储使用了ASM去管理,操作系统为RHEL6.4,Oracle11.2.0.4,rman每日全备份,使用全备份去恢复数据.恢复的机器选择了1台PC机,安装RHEL6.4,操作系统.Oracle版本均和服务器一致,区别

RMAN恢复测试

今天做RMAN恢复的测试,做恢复测试,必须在数据库有备份的前提下进行,样例中采用的是完全备份,模拟以下几种情况下的恢复: 1)数据库运行过程中数据文件全部丢失: 2)数据库运行过程中非关键数据文件丢失: 3)数据库运行过程中关键数据文件丢失: 4)联机重做日志文件/归档重做日志文件丢失(未测试): 5)增量备份下归档日志文件丢失(未测试): 在每个模拟中,都要做一次完全备份,上一个的完全备份可以给下一个模拟使用. 一.测试环境描述 系统版本:Red Hat Enterprise Linux Se

pg_rman备份恢复测试

环境描述 1.OS CentOS Linux release 7.2.1511 (Core) X64 2.PostgreSQL PostgreSQL 9.6.1 3.pg_rman pg_rman-1.3.3-pg96.tar.gz v1.3.3 注意:请下载版本对应的源码包. https://github.com/ossc-db/pg_rman/releases/download/v1.3.3/pg_rman-1.3.3-pg96.tar.gz pg_rman-1.3.3.tar.gz(此源码

xtrabackup备份恢复测试 -转

Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册 博文      博主 王恒-Henryhengwang.blog.chinaunix.net 我的项目:https://github.com/HengWang/ ChinaUnix博客技术文章推荐标准和规范 有奖征集:文集--博客系列博文管理 CU博客频道6月技术图书有奖试读活动 首页 | 博文目录 | 关于我 king_wangheng 博客访问: 486455 博文数量: 117 博客积分: 1715 博客等级: 上尉

一个简单的binlog恢复测试

日常的数据备份及恢复测试,是DBA工作重中之重的事情,所以要做好备份及测试,日常的备份常见有mysqldump+binlog备份.xtrabackup+binlog备份,无论那一种,几乎都少不了对binlog的备份,说明了binlog在数据恢复中的重要性,下面做个小测试,是工作中不少运维或者新人DBA容易犯的错. 创建一个测试表tb1: <test>([email protected]) [xuanzhi]> show create table tb1\G ***************

xtrabackup 备份mysql数据库三: innobackupex 测试一个全量和两个增量的备份恢复测试

## 查看当前库中表的数据 ([email protected]) [test]>select count(*) from t_innodb; +----------+ | count(*) | +----------+ |        0 | +----------+ 1 row in set (0.00 sec) ## 执行插入数据操作,该操作在全备之后执行完成 ([email protected]) [test]>call addTest(100000,0); ## 执行全库备份 #

oracle异机恢复测试

(一)问题背景 最近在生产环境中,开发人员误操作,使用truncate将oracle数据库某个表的数据全部删除了,在删除之后,开发人员发现自己闯祸了,于是联系值班的DBA进行紧急数据恢复. 经过分析,表被truncate后,使用一般的闪回表.闪回查询.闪回事物等方法,是不可能将数据找回来的,可以使用闪回数据库.闪回数据归档的方法来进行恢复,但是通常在生产环境中,都不会开启这2个特性,所以剩下的只有使用RMAN进行数据恢复了. 对于使用RMAN进行数据恢复,可以在生产环境上直接进行,也可以恢复到其

MySQL Drop Database之后的恢复测试

工具介绍 工具的名字叫做:  undrop-for-innodb 代码地址: https://github.com/twindb/undrop-for-innodb 官方文档: https://recovery.twindb.com/ 介绍工具的一篇ppt  http://www.slideshare.net/akuzminsky/undrop-for-innodb 当MySQL 执行 Drop Table或者 Drop Database 的时候,InnoDB并没有删除数据,数据的Page还在磁