1.1 Oracle数据库系统介绍
1.1.1 由于oracle内存机制分配策略导致修改完SGA值后与数据库中显示值不一样
某局由于业务需求,需要调整ORACLE中的shared_pool_size值大小,执行命令Alter system set shared_pool_size=262144000 scope= both后,再在数据库中的v$parameter表中查看,发现此值为268435456,以为没修改成功,屡试多次,并重启ORACLE数据库依然还是如此。
ORACLE 9i后采用granule的内存机制,所有的内存大小都是该值的整数倍。可以通过语句:
select a.ksppinm,b.ksppstvl
from sys.x$ksppi a , SYS.x$ksppcv b
where a.ksppinm='_ksmg_granule_size'
and a.indx=b.indx
来查看此值大小,可以看到该值是由_ksmg_granule_size控制,值大小为8388608。我们修改时用的值是262144000,该大小除以8388608为31.25非整数要整成32,变成32后对应的值就为268435456,与我们在v$parameter中看到的值是一致的。
经过分析ORACLE的内存划分原理,发现该值确实已经修改成功。
1.1.2 ISAG启动异常
在系统中启动TOMCAT后,启动ISAG的应用,进入<SAG_HOME>bin目录下,执行/runSLEE.sh发现报错如下:
Loading jar files: ../lib/activation.jar, ../lib/alarm_plugin.jar, ../lib/antlr.jar,
../lib/b_plugin_ismap_proxy_ttc.jar, ../lib/cert_builder.jar, ../lib/commons-net-1.4.1.jar, ../lib/db_utils.jar,
../lib/dom4j-1.6.1.jar, ../lib/iaik_javax_crypto.jar, ../lib/iaik_jce.jar, ../lib/installer.jar,
../lib/internal_policy_if.jar, ../lib/JainSipApi1.2.jar, ../lib/JainSipRi1.2.jar, ../lib/jakarta-oro-2.0.8.jar,
../lib/jaxp.jar, ../lib/jdom.jar, ../lib/jrules-engine.jar, ../lib/jsr173_api-1.0.jar, ../lib/log4j.jar,
../lib/mail.jar, ../lib/mysql.jar, ../lib/nist-sdp-1.0.jar, ../lib/nist-sip-1.2.jar, ../lib/OB.jar,
../lib/OBBiDir.jar, ../lib/OBEvent.jar, ../lib/OBFix.jar, ../lib/OBNaming.jar, ../lib/OBUtil.jar,
../lib/ojdbc14.jar, ../lib/oswego_concurrent.jar, ../lib/parser.jar, ../lib/policyutil_sag_context.jar,
../lib/policyutil_sag_ismap_if.jar, ../lib/prm_if.jar, ../lib/r_utils_ttc.jar, ../lib/resolver.jar,
../lib/sag_common_charging.jar, ../lib/sag_data_sync_context.jar, ../lib/sam.jar, ../lib/scp_message.jar,
../lib/service_version.jar, ../lib/slee.jar, ../lib/slee_agent.jar, ../lib/slee_config.jar, ../lib/slee_loader.jar,
../lib/slee_manager.jar, ../lib/slee_security.jar, ../lib/systemsla_policyutil_context.jar,
../lib/trace_plugin.jar, ../lib/URLFix.jar, ../lib/version_tool.jar, ../lib/xbean.jar, ../lib/xbean_xpath.jar,
../lib/xercesImpl.jar, ../lib/xml-apis.jar, ../lib/xmlbean_ccsi_ac.jar, ../lib/xmlbean_rpid.jar,
../lib/xmlbean_xdm.jar, ../lib/xmlbeans-qname.jar, ../lib/xmlpublic.jar
Trace: threadName=main className=SLEEDBManagerImplBase methodName=getSLEEDBManager info=Setup default JDBC
connection pool.
Trace: threadName=main className=SLEEDBManagerGeneric methodName=init info=No database failover error codes
initialized.
Trace: threadName=main className=SLEEDBManagerGeneric methodName=init info=Enabled Oracle DataSource.
Trace: threadName=main className=GeneralConnectionManager methodName=getActualConnection info=Failed to get
connection. Will skip connect for a while. error code: 17002 SQL State: null
java.sql.SQLException: Io ??????: The Network Adapter could not establish the connection
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:255)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:387)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:414)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:165)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:35)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801)
at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:297)
at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:221)
at oracle.jdbc.pool.OracleConnectionPoolDataSource.getPhysicalConnection
(OracleConnectionPoolDataSource.java:157)
at oracle.jdbc.pool.OracleConnectionPoolDataSource.getPooledConnection
(OracleConnectionPoolDataSource.java:94)
at oracle.jdbc.pool.OracleImplicitConnectionCache.makeCacheConnection
(OracleImplicitConnectionCache.java:1529)
at oracle.jdbc.pool.OracleImplicitConnectionCache.getCacheConnection
(OracleImplicitConnectionCache.java:464)
at oracle.jdbc.pool.OracleImplicitConnectionCache.getConnection(OracleImplicitConnectionCache.java:333)
at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:404)
at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:189)
at com.incomit.slee.db.GeneralConnectionManager.getActualConnection(Unknown Source)
at com.incomit.slee.db.OracleConnectionManager.getActualConnection(Unknown Source)
at com.incomit.slee.db.ConnectionRetryHandler.initConnection(Unknown Source)
at com.incomit.slee.db.ConnectionRetryHandler.getConnection(Unknown Source)
at com.incomit.slee.db.StatementRetryHandler.initStatement(Unknown Source)
at com.incomit.slee.db.StatementRetryHandler.getStatement(Unknown Source)
从报错来看,可以发现为数据库错误;可以查找oracle的相关信息
由于在启动ISAG应用前已经启动了ORACLE。并没有报错,查看其监听是否已经启动,进入ORACLE用户操作如下:
oracle@linux1:~> lsnrctl status
LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 25-9?? -2008 16:23:41
Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.69.18.60)(PORT=1521)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
Linux Error: 111: Connection refused
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
Linux Error: 2: No such file or directory
发现是监听没有启动,执行命令
oracle@linux1:~> lsnrctl start
LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 25-9?? -2008 14:20:19
Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved.
Starting /opt/oracle/product/9.2/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 9.2.0.4.0 - Production
System parameter file is /opt/oracle/product/9.2/network/admin/listener.ora
Log messages written to /opt/oracle/product/9.2/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.69.18.60)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.69.18.60)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 9.2.0.4.0 - Production
Start Date 25-9?? -2008 14:20:19
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File /opt/oracle/product/9.2/network/admin/listener.ora
Listener Log File /opt/oracle/product/9.2/network/log/listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.69.18.60)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "isag01" has 1 instance(s).
Instance "ora92", status UNKNOWN, has 1 handler(s) for this service...
Service "ora92" has 1 instance(s).
Instance "ora92", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
然后再次启动,不再报错。
1.1.3 ORACLE如何限制DBA远程登陆
ORACLE如何设置才能限制具备数据库超级管理员(SYSDBA)权限的用户远程登录,主要达到以下两个要求
1、不能通过Sql*Net远程以SYSDBA用户连接到数据库。
2、 在数据库主机上以sqlplus ‘/as sysdba’连接到数据库需要输入口令
可以通过修改spfile文件和sqlnet.ora文件实现
在spfile中设置REMOTE_LOGIN_PASSWORDFILE=NONE, 在SQL*PLUS中以DBA登录,执行以下语句:
SQL>alter system set REMOTE_LOGIN_PASSWORDFILE = NONE scope = spfile;
(2) 禁用 SYSDBA 角色的自动登录。
在sqlnet.ora文件中,用文本编缉器设置$ORACLE_HOME/network/admin/sqlnet.ora文件中参数SQLNET.AUTHENTICATION_SERVICES=NONE
验证:
(1) 以Oracle用户登陆到系统中。
(2) 以sqlplus ‘/as sysdba’登陆到sqlplus环境中。
(3) 使用show parameter命令来检查参数REMOTE_LOGIN_PASSWORDFILE是否设置为NONE。
SQL>Show parameter REMOTE_LOGIN_PASSWORDFILE
(4) 检查在$ORACLE_HOME/network/admin/sqlnet.ora文件中参数SQLNET.AUTHENTICATION_SERVICES是否被设置成NONE。
1.1.4 如何为数据库监听器(LISTENER)的关闭和启动设置密码
oracle9I中为了oracle系统的安全,目前存在系统需要为数据库监听器(LISTENER)的关闭和启动设置密码,可以通过设置实现LISTENER的启动和关闭设置密码,
$ lsnrctl
LSNRCTL> change_password
Old password: <OldPassword> Not displayed
New password: <NewPassword> Not displayed
Reenter new password: <NewPassword> Not displayed
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521)(IP=FIRST)))
Password changed for LISTENER
The command completed successfully
LSNRCTL> save_config
验证:
检查$ORACLE_HOME/network/admin/listener.ora文件中是否设置参数PASSWORDS_LISTENER。
设置密码后注意不要忘记密码。
Oracle数据库的listener程序有安全隐患,如果远程主机存在一个同本机数据库同样配置的listener.ora文件,那么在远程主机上可以关掉本机数据库的listener。攻击者可以利用这个问题随意关闭oracle tnslsnr服务器或者设置新的口令,这将影响合法用户的正常使用。攻击者也可以获取数据库的一些细节信息以发动进一步攻击。结合其他漏洞,攻击者甚至可以在目标系统上创建或者修改文件,进而入侵系统。
给listener加上口令保护后,启动listener不需要口令,但关闭listener、查看listener的状态都需要口令。
切换到oracle的管理员,执行下列命令
$ORACLE_HOME/bin/lsnrctl
LSNRCTL> change_password
Old password: < 原来的口令> < -- 如果原来没有设置口令就直接回车,否则输入原来的口令
New password: < 新口令>
Reenter new password: < 新口令>
Connecting to (ADDRESS=(PROTOCOL=ipc)(KEY=XXX))
Password changed for LISTENER
The command completed successfully
LSNRCTL> set password
Password: < 输入新口令>
LSNRCTL> save_config (此步重要,保存当前设置)
1.1.5 Oracle数据库启动和关闭的几种模式介绍
数据库安装、维护中,启动和关闭数据库乃是例行工作。Oracle数据库的启动和关闭模式有很多种,如何选择正确的方式对我们至关重要。
下面简单介绍一下Oracle9i数据库的几种启动、关闭模式,希望对大家平时的维护有所帮助,以便选择正确的模式。
一、启动
语法:startup [force] [pfile=文件名] [exclusive|shared] [mount 数据库名|normal 数据库名] [nomount]
1、正常启动
sql>conn sys/sys as sysdba;
sql>startup
也可在启动时指定数据库名。
sql>startup ora9
2、安装和非安装启动
安装启动的选项是mount,表示例程只将数据库装入,而不打开数据库;非安装启动的选项是nomount,表示只建立数据库现场,并不装入数据库,当然也不能打开。
sql>startup mount --安装启动
sql>startup nomount--非安装启动
3、独占和共享启动
独占启动的选项是exclusive,表示只允许一个例程使用该数据库;共享启动的参数是shared,表示允许多个例程并行使用该数据库,即将数据库装入多个现场。
4、约束启动
约束启动的选项是restrict,它启动数据库时装入并打开它,但是此时的数据库只能为有特殊权限的数据库管理员使用,一般用户不能联入到该数据库。
sql>startup restrict
一般说来,当用户有create session权限时,可以联入数据库,但对于restrict方式启动的数据库,则只有用户具有restricted session系统权限才允许联入。
若要在数据库运行过程中改变这一方式,可用alter system命令。
sql>alter system disable restricted session;
也可以先将数据库关闭再重新以非restrict方式启动数据库。
5、强制启动
若在正常启动数据库时遇到一些麻烦,或在上次关闭数据库时不能正常关闭,则可以采取强制启动,其选项是force。
sql>startup force
6、带初始化参数文件的启动
初始化参数文件在数据库启动时由系统读取,设置一些全局参数,它并不影响数据库的运行方式。
sql>startup pfile=d:\oracle\admin\site\pfile\init.ora
技巧:用alter database可以进行一些启动模式转换,但是转换的类型十分有限,比如从mount模式下将数据库打开,则可用以下命令:
sql>alter database open;
还可以从mount状态转为mount状态,如下所示:
sql>alter database mount;
二、关闭
1、正常关闭
正常关闭数据库所用的选项是normal,数据库在关闭前将检查所有的连接,并且发出命令后不允许再有新的用户连接,在等待所有连接都断开后再关闭数据库,再次启动数据库不需要任何恢复过程。
sql>shutdown normal;
2、紧急关闭
该方式用在某些紧急的情况下,比如通知马上停电,此时需要紧急关闭数据库以应付这些情况。这种方式用的选项是immediate,在这种方式下并不等待所有的用户断开连接再关闭,而是由系统断开连接,然后关闭数据库。
sql>shutdown immediate;
一旦执行了这条命令,则将当前正在处理的sql语句马上停止,然后将所有未提交的事务回退,并且不等待当前联入数据库的用户断开连接,而是由系统强行将各个联接断开。在下次启动数据库时要执行恢复动作,不过是由系统自动执行的,用户不必去了解它。
3、异常关闭
异常关闭选项是abort,此种方式下系统并不做任何检查和断开用户操作以及回退操作,而是直接将数据库现场撤销,这样现场中的数据库数据当然就无效了,数据库自然也就被关掉了。
sql>shutdown abort;
以abort方式关闭数据库时只有一行关闭信息表示关闭了数据库现场。以abort方式关闭的数据库再次启动时必须要进行恢复动作,这些恢复操作同样是系统自动来完成的,需要的时间较长。
1.1.6 sqlplus登陆数据库失败案例
在oracle用户下,使用sqlplus "/as sysdba"登陆数据失败,产生如下错误:
mdsp>sqlplus "/as sysdba"
SQL*Plus: Release 9.2.0.7.0 - Production on 星期五 2月 15 15:04:39 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
请输入用户名:
产生错误:
ERROR:
ORA-01031: insufficient privileges
因为以前使用sqlplus "/as sysdba"以超级管理员登陆是没有问题,回忆最近的配置更改,曾经将/etc/passwd文件的读写权限由644改为了640,将passwd文件读写权限改回644后,以sqlplus "/as sysdba"登陆恢复正常
将/etc/passwd文件读写权限改回644后,问题解决
使用sqlplus "/as sysdba"以超级管理员登陆数据库时,是需要读取/etc/passwd文件的。
1.1.7 Import导入慢问题处理
一次数据库移植,按照用户方式导入,发现导入某个表时非常慢,经过检查发现该表含有long字段
1、经过查询资料和分析,发现在导入的时候将commit数设置为y,commit=y就是每次一个读取一个缓冲区再提交,如果把commit=n,就是一个表导完才提交。
2、如果 COMMIT=Y ,IMPORT操作遇到long字段的时候,是一条纪录一条纪录读取,每导入一条再提交一条,所以最后导致很慢。
将commit参数设置为n后,速度提高了很多
遇到导入long、clob字段的时候,需要将commit设置为n,但是需要将undo tablespace设置得要大一些
1.1.8 oracle进程导致cpu占用率非常高问题的解决步骤
oracle数据库所在的操作系统查看cpu占用率接近达到100%
1、检查系统
sar -u 5 5
2、 看谁在用CPU
topas
ps -ef |grep ora #检查第四列,C的大小(unit,100 per cpu)
3、检查CPU数量
/usr/sbin/bindprocessor -q
lsattr El proc0
4、两种可能:
1: A Background (instance) process
2: An oracle (user) process #此种可能最大。
5、如果是用户进程:那么高CPU的主要原因有:
Large Queries, Procedure compilation or execution,
Space management and Sorting
5.1 查看每个Session的CPU利用情况:
select ss.sid,se.command,ss.value CPU ,se.username,se.program
from v$sesstat ss, v$session se
where ss.statistic# in
(select statistic#
from v$statname
where name = 'CPU used by this session')
and se.sid=ss.sid
and ss.sid>6
order by ss.sid
5.2: 比较上述Session
比较一下哪个session的CPU使用时间最多,然后查看该Session的具体情况:
select s.sid, event, wait_time, w.seq#, q.sql_text
from v$session_wait w, v$session s, v$process p, v$sqlarea q
where s.paddr=p.addr and
s.sid=&p and
s.sql_address=q.address;
5.3:查看
得到上述信息后,查看相应操作是否有hash joins 和 full table scans。如果有hash joins 和 full table scans那么必须创建相应的Index或者检查Index是否有效。
另外必须检查是否有并行的查询存在和同一时刻有多个用户在执行相同的SQL语句,如果有必须关闭并行的查询和任何类型的并行提示(hints);如果查询使用intermedia数据,那么为了减少总的Index大小,必须限制使用Intermedia的Worldlist。(try restricting the wordlist that intermedia uses to help reduce the total indexsize)。
6、注意事项
上述方案只能根据已经运行完成的操作,对于正在执行的长时间操作只能等操作完成后才能检测得到。因此我们可以通过另外一个很好的工具来检测正在运行的长时间操作语句。v$session_longops,这个视图显示那些操作正在被运行,或者已经完成。每个process完成后会刷新本视图的信息。
7、怎样寻找集中使用CPU的Process:
很多时候会发现有N个Process在平均分享着CPU的利用率,这种情况唯一的可能性就是这些Process在执行着相同的Package或者Query.
这种情况:建议通过statspack,在CPU高利用率额时候运行几个快照,然后根据这些快照检查Statspack报告,检查报告中最TOP的Query。然后使用 sql_trace and tkprof 工具去跟踪一下。
同时检查buffer cache 的命中率是否大雨95%。
同时在报告中还需要检查一下table scans (long tables),看是否在报告生成期间有存在全表扫描。
8、参数
另外还有一些不是特别重要的,但是也必须关心检查的参数可能消耗CPU
1.1.9 存储过程中应用Trim()函数导致性能降低
oracle,存储过程,效率,性能,低,下降,慢,trim,结果集,SQL
某局点客服系统Oracle数据库在执行P_SCN_LISTUSER存储过程时,查询时间约1分钟
1、 跟踪磁盘IO性能,发现执行该存储过程时磁盘“读”操作特别频繁。怀疑是数据库在查询整表,可能存储过程引用的表没有建立索引;
2、 查询存储过程中所涉及的表t_scn_customer_info,发现相关字段都作了索引;
3、 分析存储过程,发现select语句中存在对索引字段使用Trim()函数的情况。
4、 如果对索引字段使用Trim()函数,则索引会失效,从而导致数据库查询整表,效率降低
修改存储过程,去除Trim()函数。查询速度提高。每次查询耗时不到1秒
如果对索引字段使用Trim()函数,则索引会失效,从而导致数据库查询整表,效率降低。今后在编写SQL语句时需要注意。
1.1.10 oracle数据库异常关闭后无法启动问题处理
某系统突然掉电,系统启动后发现Oracle无法启动
启动时报如下错误:
ORA-01102 cannot mount database in EXCLUSIVE mode
出现1102错误可能有以下几种可能:
一、在HA系统中,已经有其他节点启动了实例,将双机共享的资源(如磁盘阵列上的裸设备)占用了;
二、说明Oracle被异常关闭时,有资源没有被释放,一般有以下几种可能,
1、 Oracle的共享内存段或信号量没有被释放;
2、 Oracle的后台进程(如SMON、PMON、DBWn等)没有被关闭;
3、 用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。
首先,虽然我们的系统是HA系统,但是备节点的实例始终处在关闭状态,这点通过在备节点上查数据库状态可以证实。
其次、是因系统掉电引起数据库宕机的,系统在接电后被重启,因此我们排除了第二种可能种的1、2点。最可疑的就是第3点了。
查$ORACLE_HOME/dbs目录:
$ cd $ORACLE_HOME/dbs
$ ls sgadef*
sgadef* not found
$ ls lk*
lkORA92
果然,lk<sid>文件没有被删除。将它删除掉
$ rm lk*
再启动数据库,成功。
如果怀疑是共享内存没有被释放,可以用以下命令查看:
$ipcs -mop
IPC status from /dev/kmem as of Thu Jul 6 14:41:43 2006
T ID KEY MODE OWNER GROUP NATTCH CPID LPID
Shared Memory:
m 0 0x411c29d6 --rw-rw-rw- root root 0 899 899
m 1 0x4e0c0002 --rw-rw-rw- root root 2 899 901
m 2 0x4120007a --rw-rw-rw- root root 2 899 901
m 458755 0x0c6629c9 --rw-r----- root sys 2 9113 17065
m 4 0x06347849 --rw-rw-rw- root root 1 1661 9150
m 65541 0xffffffff --rw-r--r-- root root 0 1659 1659
m 524294 0x5e100011 --rw------- root root 1 1811 1811
m 851975 0x5fe48aa4 --rw-r----- oracle oinstall 66 2017 25076
然后它ID号清除共享内存段:
$ipcrm –m 851975
对于信号量,可以用以下命令查看:
$ ipcs -sop
IPC status from /dev/kmem as of Thu Jul 6 14:44:16 2006
T ID KEY MODE OWNER GROUP
Semaphores:
s 0 0x4f1c0139 --ra------- root root
... ...
s 14 0x6c200ad8 --ra-ra-ra- root root
s 15 0x6d200ad8 --ra-ra-ra- root root
s 16 0x6f200ad8 --ra-ra-ra- root root
s 17 0xffffffff --ra-r--r-- root root
s 18 0x410c05c7 --ra-ra-ra- root root
s 19 0x00446f6e --ra-r--r-- root root
s 20 0x00446f6d --ra-r--r-- root root
s 21 0x00000001 --ra-ra-ra- root root
s 45078 0x67e72b58 --ra-r----- oracle oinstall
根据信号量ID,用以下命令清除信号量:
$ipcrm -s 45078
如果是Oracle进程没有关闭,用以下命令查出存在的oracle进程:
$ ps -ef|grep ora
oracle 29976 1 0 Jun 22 ? 0:52 ora_dbw0_ora92
oracle 29978 1 0 Jun 22 ? 0:51 ora_dbw1_ora92
oracle 5128 1 0 Jul 5 ? 0:00 oracleora92 (LOCAL=NO)
... ...
然后用kill -9命令杀掉进程
$kill -9 <PID>
当发生1102错误时,可以按照以下流程检查、排错:
如果是HA系统,检查其他节点是否已经启动实例;
检查Oracle进程是否存在,如果存在则杀掉进程;
检查信号量是否存在,如果存在,则清除信号量;
检查共享内存段是否存在,如果存在,则清除共享内存段;
检查锁内存文件lk<sid>和sgadef<sid>.dbf是否存在,如果存在,则删除。
1.1.11 怎样限制特定IP访问Oracle数据库
客户要求只允许某些特定IP访问Oracle数据库
有些文档说增加或修改 protocol.ora 文件,但真正起作用的是sqlnet.ora文件,修改sqlnet.ora是最好最快方法
在sqlnet.ora中增加如下部分:
tcp.validnode_checking=yes
#允许访问的IP
tcp.invited_nodes=(ip1,ip2……)
#禁止访问的IP
tcp.excluded_nodes=(ip1,ip2……)
之后重新启动监听器即可。
需要注意的地方:
1、tcp.invited_nodes与tcp.excluded_nodes都存在时,以tcp.invited_nodes为主。
2、一定要许可或不要禁止服务器本机的IP地址,否则通过lsnrctl将不能启动或停止监听,因为该过程监听程序会通过本机的IP访问监听器。
3、修改之后,一定要重起监听才能生效,而不需要重新启动数据库。
4、任何平台都可以,但是只适用于TCP/IP协议。