利用RAC环境解决本机SQLPLUS的SP2-1503错误

故障现象:

$ sqlplus / as sysdba

SP2-1503: Unable to initialize Oracle call interface

SP2-0152: ORACLE may not be functioning properly

分析:网上都说是timezone和timezlrg文件的权限不正确,可我压根没这两个文件了,

怎么办,且看如下分析

--看看timezone和timezlrg文件是否正常

$ cd /home/oracle/database/oracore/zoneinfo

$ ls -lt

总计 16

-rw-r--r--   1 oracle   dba            4672  6月01 2006   readme.txt

--竟缺失了,马上想到去RAC的另外一个节点取文件过来

--FTP连过去

$ ftp 192.168.1.56

连接至 192.168.1.56。

220 p550b FTP server (Version 4.2 Tue Nov 14 12:49:19 CST 2006) ready.

名称(192.168.1.56:root):root

331 Password required for root.

密码:

230-Last unsuccessful login: Thu Dec 30 10:43:55 BEIST 2010 on /dev/pts/4 from 192.168.180.27

230-Last login: Fri Apr  1 09:27:15 BEIST 2011 on /dev/pts/1 from 192.168.180.29

230 User root logged in.

--进入到远程主机相应目录

ftp> cd /home/oracle/database/oracore/zoneinfo

250 CWD command successful.

ftp> pwd

257 "/home/oracle/database/oracore/zoneinfo" is current directory.

ftp> get *.dat

--FTP怎么会不支持模糊,先输入详细名称完成任务吧

200 PORT command successful.

550 *.dat: No such file or directory

ftp> ls -lt

200 PORT command successful.

150 Opening data connection for /bin/ls.

total 1128

-rw-r--r--   1 oracle   dba          404884 Jan 11 2007  timezlrg.dat

-rw-r--r--   1 oracle   dba          161123 Jan 11 2007  timezone.dat

-rw-r--r--   1 oracle   dba            4672 Jun 01 2006  readme.txt

226 Transfer complete.

--FTP获取远程文件

ftp> get timezlrg.dat

200 PORT command successful.

150 Opening data connection for timezlrg.dat (404884 bytes).

226 Transfer complete.

在 2.03e-318 秒内接收到 4589539693338558464 字节(5930 千字节/秒)

时间: 2024-09-13 23:12:45

利用RAC环境解决本机SQLPLUS的SP2-1503错误的相关文章

Oracle 11.2 RAC环境中CRSD进程简介

在11.2中,CRSD进程不再是RAC中最关键的进程之一. 如果对10g RAC比较熟悉,应该清楚CRSD进程的重要性,Oracle在操作系统启动后,就是通过启动这个进程然后启动整个CLUSTER以及数据库的. 在11.2的RAC中,Oracle调整了ASM,使得OCR和VOT可以存储在ASM磁盘组中.ASM是CLUSTER所支持的一个组件,而CLUSTER启动所需的OCR和VOT却要放在ASM中,这其实要解决一个先有鸡还是先有蛋的问题.最终Oracle通过OHASD进程的方式解决了这个问题,而

oracle如何利用STANDBY将单实例数据库升级为RAC环境(三)

利用Oracle的STANDBY技术,可以将单实例数据库升级到RAC数据库.这种方式可以有效的降低单实例迁移到RAC环境的停机时间. 这篇文章描述单实例环境与RAC环境的SWITCHOVER过程. 前面已经成功搭建了单实例数据库TEST11G的RAC环境STANDBY数据库TEST11GR.STANDBY数据库的两个实例可以同时以READ ONLY方式启动. 下面为了执行SWITCHOVER操作,可以先关闭实例2: bash-3.00$ export ORACLE_SID=test11gr2 b

oracle如何利用STANDBY将单实例数据库升级为RAC环境(一)

利用Oracle的STANDBY技术,可以将单实例数据库升级到RAC数据库.这种方式可以有效的降低单实例迁移到RAC环境的停机时间. 这篇文章介绍STANDBY数据库建立的准备工作. 首先需要确保目标服务器上的RAC环境已经建立,如果使用ASM作为存储机制,则ASM实例也配置完成. 下面开始STANDBY数据库建立的过程,更改源数据库的FORCE LOGGING属性: bash-3.00$ sqlplus "/ as sysdba" SQL*Plus: Release11.1.0.6.

oracle如何利用STANDBY将单实例数据库升级为RAC环境(四)

利用Oracle的STANDBY技术,可以将单实例数据库升级到RAC数据库.这种方式可以有效的降低单实例迁移到RAC环境的停机时间. 这篇文章描述整个操作过程中碰到的错误. 最开始碰了几个初始化参数设置的小错误,主要问题是FLASH_RECOVERY_AREA设置到ASM实例上导致了问题: SQL> startup nomount pfile=/export/home/oracle/inittest11gr1.ora ORA-01261: Parameter db_recovery_file_d

oracle如何利用STANDBY将单实例数据库升级为RAC环境(二)STANDBY数据库的建立

利用Oracle的STANDBY技术,可以将单实例数据库升级到RAC数据库.这种方式可以有效的降低单实例迁移到RAC环境的停机时间. 这篇文章介绍STANDBY数据库的建立. 上一篇完成了绝大部分准备的工作,下面在打开数据库之前,还要设置一下目标数据库上的密码文件. 在STANDBY的RAC环境的两个节点上分别拷贝密码文件: bash-3.00$ cd $ORACLE_HOME/dbs bash-3.00$ ftp 172.0.2.61 Connected to 172.0.2.61. 220

分析解决11gR2 双节点RAC环境下的gc cr block busy/gc buffer busy acquire等待

?  系统环境 两节点的RAC:AIX6.1+Oracle 11.2.0.3.3   ?  AWR里展示出来的各种症状(数据来自实例2) 虽然应用没有报障,但AWR报告里的各种迹象已经很明显了 (1)     gc buffer busy acquire排进了Top 5 Timed Foreground Events 图-1     (2)     除去DB CPU在gc buffer busy acquire之后的就是gc cr block busy了 图-2     (3)     2h21

【OGG】RAC环境下配置OGG单向同步 (四)

[OGG]RAC环境下配置OGG单向同步 (四) 一.1  BLOG文档结构图       一.2  前言部分   一.2.1  导读 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① RAC环境下配置OGG单向同步     注意:本篇BLOG中代码部分需要特别关注的地方我都用黄色背景和红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33,thread 2的最大归档日志号为43是需要特别关注的地方.   List

Oracle RAC环境单独节点插入数据也会导致全局等待(上)

在RAC环境中,登陆到一个实例,在处理的数据完全与另外实例内存中数据无关的情况下,也会导致gc全局等待产生. 这一篇描述现象. 环境如下: SQL> conn yangtk/yangtk 已连接. SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database10gEnterpriseEdition Release10.2.

Oracle RAC环境中EXECUTE_EM_DBMS_JOB_PROCS

今天一个客户咨询,他们的RAC环境中,EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS过程频繁启动,而且占用了大量的系统资源. 这个任务每分钟运行一次,而且每次都排在top中的前面. 这个job是EM用了维护管理工作的JOB,而这个JOB导致性能问题的相关bug也不再少数,比如Bug 7759386. 和客户确认,发现他们根本不使用EM,那么解决这个问题的最简单的办法就是删除这个维护JOB. 利用SYSMAN用户登陆执行这个SQL: SQL> conn sysm