标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,770)
- DB2 (22)
- MySQL (77)
- Oracle (1,611)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (592)
- Oracle安装升级 (98)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- Oracle 19c 202507补丁(RUs+OJVM)-19.28
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
分类目录归档:Oracle
记录一次比较棘手数据库恢复要点
在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下
ORA-00704/ORA-01555错误
Fri May 4 21:04:21 2012 select ctime, mtime, stime from obj$ where obj# = :1 Fri May 4 21:04:21 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 1286288 ORA-1092 signalled during: alter database open resetlogs... 这里的提示可以看出obj$基表中有事务存在,查询这个表的时候,要去找40号回滚段中相关数据;通过非常规方法, 查找到40号回滚段的状态是offliine了(这个查询出来的信息和是否使用隐含参数无关). 问题原因,为什么40号回滚段变得offline? Fri May 4 17:36:26 2012 alter tablespace undotbs offline Fri May 4 17:36:26 2012 ORA-1109 signalled during: alter tablespace undotbs offline... Fri May 4 17:37:29 2012 alter database datafile '/dev/rundodbs01' offline drop Fri May 4 17:37:29 2012 Completed: alter database datafile '/dev/rundodbs01' offline drop 因为强制offline 了file# 2文件导致(一个undo表空间文件) 解决方法: 1.bbed提交事务 因为现在生产的trace文件中未有关于obj$ 未提交事务的记录,做10046也为发现该记录,如果要使用bbed修改该事务, 那需要dump obj$相关的数据块(在mount状态下dump),然后找到相关事务,再修改 2.强制让file# 2 online 因为在resetlogs前file#2 已经offline掉了,所以要使得该文件能够成功online,需要先推进scn
ORA-00600[krhpfh_03-1209]
SQL> recover database until cancel; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [krhpfh_03-1209], [2], [782415504], [782428968], [3987078030], [2379], [0], [0] ORA-01110: data file 2: '/dev/rundodbs01' 问题原因: 数据库处于非归档模式下,连续三次resetlogs,引起该bug 解决办法: 重建控制文件 但是这里问题出现了,因为file# 2的resetlogs scn和其他数据文件不一致,导致在file# 2 online的前提下,无法重建. 这样就处在了一个循环中(需要online file# 2 又要重建控制文件),这样的问题,可以通过bbed修改file# 2的resetlogs scn完成 或者先让file# 2 offline(没有加drop)掉,重建控制文件(除掉file# 2的文件记录)
ORA-00600[25025]
SMON: enabling cache recovery Fri May 4 22:36:36 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 1167402 错误原因: 因为有undo文件不在undo对应的表空间中,而我们的file# 2文件确实是undo文件,而且重建控制文件时候未加入进来 解决办法: undo_management = AUTO undo_tablespace = UNDODBS(file# 2属于该表空间) 修改为 undo_management = MANUAL undo_tablespace = SYSTEM 或者bbed修改file# 2的header,然后重建控制文件
ORA-00600[4137]
Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:20:52 2012 create undo tablespace undotbs3 datafile '/dev/rundodbs21' size 20400M Fri May 4 23:23:47 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:23:48 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_pmon_1520126.trc: ORA-00474: SMON process terminated with error Fri May 4 23:23:48 2012 PMON: terminating instance due to error 474 Instance terminated by PMON, pid = 1520126 错误原因: _smon_internal_errlimit(limit of SMON internal errors) SMON遇到了内部错误,最大允许100次, 不断计数增长,达到100的时候,数据库smon进程自动down掉,从而导致数据库down 解决办法: 1.临时解决办法:设置_smon_internal_errlimit一个较大值 3.根本解决办法:使用undo隐含参数,删除有问题undo 回滚段和undo表空间或者使用10513 事件
Bind Variable Peeking 测试
相关参数
SQL> select * from v$version; BANNER --------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production SQL> show parameter optimizer_mode; NAME TYPE VALUE ------------------------------------ ---------------------- ---------------- optimizer_mode string ALL_ROWS SQL> show parameter cursor_sharing; NAME TYPE VALUE ------------------------------------ ---------------------- ---------------- cursor_sharing string EXACT SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description 2 from x$ksppi a,x$ksppcv b 3 where a.inst_id = USERENV ('Instance') 4 and b.inst_id = USERENV ('Instance') 5 and a.indx = b.indx 6 and upper(a.ksppinm) LIKE upper('%¶m%') 7 order by name 8 / Enter value for param: _optim_peek_user_binds old 6: and upper(a.ksppinm) LIKE upper('%¶m%') new 6: and upper(a.ksppinm) LIKE upper('%_optim_peek_user_binds%') NAME VALUE DESCRIPTION -------------------------------- ------------------------ ---------------------------------- _optim_peek_user_binds TRUE enable peeking of user binds
创建模拟表
SQL> create table t_xifenfei(id number,name varchar2(30)); Table created. SQL> begin 2 for i in 1..100000 loop 3 insert into t_xifenfei values(i,'xifenfei'); 4 end loop; 5 commit; 6 end; 7 / PL/SQL procedure successfully completed. SQL> update t_xifenfei SET name='www.xifenfei.com' where mod(id,20000)=0; 5 row updated. SQL> commit; Commit complete. SQL> create index i_xifenfei on t_xifenfei(name); Index created.
默认收集统计信息,查看执行计划
SQL> exec DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE); PL/SQL procedure successfully completed. SQL> set autot trace exp SQL> select id from t_xifenfei where name='xifenfei'; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='xifenfei') SQL> select id from t_xifenfei where name='www.xifenfei.com'; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='www.xifenfei.com') --这里可以发现,对于这样少量的列的情况,没有选择一个合适的执行计划
准确收集统计信息
SQL> exec DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE, 2 method_opt => 'FOR ALL COLUMNS SIZE 254',estimate_percent => 100); PL/SQL procedure successfully completed.
再次查看执行计划
SQL> select id from t_xifenfei where name='www.xifenfei.com'; Execution Plan ---------------------------------------------------------- Plan hash value: 1926396081 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 14 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 1 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("NAME"='www.xifenfei.com') Statistics ---------------------------------------------------------- 0 recursive calls 1 db block gets 320 consistent gets 0 physical reads 0 redo size 418 bytes sent via SQL*Net to client 419 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 5 rows processed SQL> select id from t_xifenfei where name='xifenfei'; 99995 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 99999 | 1367K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 99999 | 1367K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='xifenfei') Statistics ---------------------------------------------------------- 0 recursive calls 1 db block gets 6970 consistent gets 0 physical reads 0 redo size 1455968 bytes sent via SQL*Net to client 73745 bytes received via SQL*Net from client 6668 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 99995 rows processed --通过这里可以看出在完整的收集表和index包括直方图信息后,数据库执行计划正常 --也说明一点:在数据列分布不均匀的时候,依靠数据库自动收集直方图还是不怎么拷贝.
使用AUTOTRACE测试
SQL> set autot trace exp SQL> var a varchar2(30); SQL> exec :a := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select id from t_xifenfei where name=:a; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"=:A) --这里可以发现11g的Bind Variable Peeking 没有使用正确的执行计划,其实这个是AUTOTRACE本身的bug导致
收集下面sql执行计划(peeking测试需要)get_plan.sql脚本
SQL> select * from t_xifenfei where name='wwww.xifenfei.com' and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 2708637417 select * from t_xifenfei where name='wwww.xifenfei.com' and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 3 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"='wwww.xifenfei.com') SQL> select * from t_xifenfei where name='xifenfei' and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 1355242984 select * from t_xifenfei where name='xifenfei' and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"='xifenfei')) --这里可以看到,两个执行计划都我们希望的
测试peeking功能
SQL> alter system flush shared_pool; System altered. SQL> select * from t_xifenfei where name='xifenfei' and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 2860562673 select * from t_xifenfei where name='xifenfei' and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"='xifenfei')) SQL> var b varchar2(30); SQL> exec :b := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"=:B)) --重新硬解析 SQL> alter system flush shared_pool; System altered. SQL> var b varchar2(30); SQL> exec :b := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 6 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"=:B) SQL> var b varchar2(30); SQL> exec :b := 'xifenfei'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 6 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"=:B) --虽然oracle 11g宣称在在Bind Variable Peeking上增强了很多, --但是这里的实验,依然证明他存在问题,导致执行计划不正确
通过整体实验过程,证明几个问题:
1.默认的的DBMS_STATS收集统计信息不一定使得所有执行计划均正确,特别在数据很不均匀分布时.
2.AUTOTRACE不能跟踪Bind Variable Peeking
3.Bind Variable Peeking是在硬解析时候生效,虽然11g进行了改善,但是有些时候效果还是不明显,如果数据很不均匀,在发现sql语句很多不合适的时候,建议先删除该sql的执行计划,让其再次硬解析,碰碰运气,如果一直效果不好,建议不适用绑定参数形式(正确的执行计划,更多的硬解析)
4._optim_peek_user_binds参数可以关闭Bind Variable Peeking功能,很不推荐.
发表在 Oracle性能优化
评论关闭
通过ftp/http拷贝asm中文件
1.检查Oracle XML Database组件
SQL> select comp_name, status, version from DBA_REGISTRY where comp_name='Oracle XML Database'; COMP_NAME STATUS VERSION ------------------------- ---------------------- ------------------------------ Oracle XML Database VALID 11.2.0.3.0 SQL> select count(*) from dba_objects where owner='XDB' and status='INVALID'; COUNT(*) ---------- 0
2.配置xdb的ftp和http
[oracle@rac1 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Tue May 1 12:05:27 2012 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> execute dbms_xdb.sethttpport(8080); PL/SQL procedure successfully completed. SQL> execute dbms_xdb.setftpport(2100); PL/SQL procedure successfully completed. SQL> commit; Commit complete. SQL> select dbms_xdb.GETFTPPORT() from dual; DBMS_XDB.GETFTPPORT() --------------------- 2100 SQL> select dbms_xdb.GETHTTPPORT() from dual; DBMS_XDB.GETHTTPPORT() ---------------------- 8080 --根据你的需求,可以选择一个即可 SQL> show parameter dispatchers; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------- dispatchers string (PROTOCOL=TCP) (SERVICE=XFFXDB) --dispatchers参数会自动配置,这里需要说明,MOS中说的sidxdb是不恰当的,我这里是db_namexdb --因为我这里是rac,sid为XFF1,总之相信自动配置
3.查看监听
[oracle@rac1 ~]$ lsnrctl status LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 01-MAY-2012 12:09:14 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production Start Date 01-MAY-2012 11:51:13 Uptime 0 days 0 hr. 18 min. 1 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/11.2.0/grid/network/admin/listener.ora Listener Log File /u01/app/gridbase/diag/tnslsnr/rac1/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.31)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.33)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=rac1)(PORT=8080))(Presentation=HTTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=rac1)(PORT=2100))(Presentation=FTP)(Session=RAW)) Services Summary... Service "+ASM" has 1 instance(s). Instance "+ASM1", status READY, has 1 handler(s) for this service... Service "XFF" has 1 instance(s). Instance "XFF1", status READY, has 1 handler(s) for this service... Service "XFFXDB" has 1 instance(s). Instance "XFF1", status READY, has 1 handler(s) for this service... The command completed successfully --以下两条监听是自动增加上去,如果没有自动增加,需要手工增加并且重启或者重新加载监听 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=rac1)(PORT=8080))(Presentation=HTTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=rac1)(PORT=2100))(Presentation=FTP)(Session=RAW))
4.ftp基本操作
[oracle@rac1 ~]$ ftp -n ftp> open rac1 2100 Connected to rac1. 220- rac1 Unauthorised use of this FTP server is prohibited and may be subject to civil and criminal prosecution. 220 rac1 FTP Server (Oracle XML DB/Oracle Database) ready. 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type ftp> user system xifenfei 331 pass required for SYSTEM 230 SYSTEM logged in ftp> ls 227 Entering Passive Mode (192,168,1,31,181,5) 150 ASCII Data Connection drw-r--r-- 2 SYS oracle 0 SEP 18 17:49 OLAP_XDS drw-r--r-- 2 SYS oracle 0 SEP 18 17:47 home drw-r--r-- 2 SYS oracle 0 SEP 18 18:02 images drw-r--r-- 2 SYS oracle 0 SEP 18 17:49 olap_data_security drw-r--r-- 2 SYS oracle 0 SEP 18 17:43 public drw-r--r-- 2 SYS oracle 0 SEP 18 17:44 sys -rw-r--r-- 1 SYS oracle 0 MAY 01 04:06 xdbconfig.xml drw-r--r-- 2 SYS oracle 0 SEP 18 17:49 xds 226 ASCII Transfer Complete ftp> cd sys 250 CWD Command successful ftp> cd asm 250 CWD Command successful ftp> ls 227 Entering Passive Mode (192,168,1,31,98,133) 150 ASCII Data Connection drw-r--r-- 2 SYS oracle 0 MAY 01 04:14 XIFENFEI drw-r--r-- 2 SYS oracle 0 MAY 01 04:14 DATA 226 ASCII Transfer Complete ftp> cd xifenfei 250 CWD Command successful ftp> ls 227 Entering Passive Mode (192,168,1,31,151,70) 150 ASCII Data Connection drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 XFF drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 ASM 226 ASCII Transfer Complete ftp> cd xff 250 CWD Command successful ftp> ls 227 Entering Passive Mode (192,168,1,31,100,14) 150 ASCII Data Connection drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 DATAFILE drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 CONTROLFILE drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 ONLINELOG drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 TEMPFILE drw-r--r-- 2 SYS oracle 0 MAY 01 04:15 PARAMETERFILE -rw-r--r-- 1 SYS oracle 3584 MAY 01 04:15 spfileXFF.ora 226 ASCII Transfer Complete ftp> cd xff/datafile 250 CWD Command successful ftp> ls 227 Entering Passive Mode (192,168,1,31,30,63) 150 ASCII Data Connection -rw-r--r-- 1 SYS oracle 744497152 MAY 01 04:20 SYSTEM.256.776961315 -rw-r--r-- 1 SYS oracle 618668032 MAY 01 04:20 SYSAUX.257.776961315 -rw-r--r-- 1 SYS oracle 83894272 MAY 01 04:20 UNDOTBS1.258.776961317 -rw-r--r-- 1 SYS oracle 6291456 MAY 01 04:20 user_dd.dbf -rw-r--r-- 1 SYS oracle 26222592 MAY 01 04:20 UNDOTBS2.264.776961693 -rw-r--r-- 1 SYS oracle 157294592 MAY 01 04:20 xifenfei01.dbf 226 ASCII Transfer Complete ftp> get xifenfei01.dbf local: xifenfei01.dbf remote: xifenfei01.dbf 227 Entering Passive Mode (192,168,1,31,143,34) 150 ASCII Data Connection 550- Error Response ORA-31198: Mismatch in number of bytes transferred due to non-binary mode 550 End Error Response 270340 bytes received in 0.053 seconds (5e+03 Kbytes/s) ftp> binary 200 Type set to I. ftp> get xifenfei01.dbf local: xifenfei01.dbf remote: xifenfei01.dbf 227 Entering Passive Mode (192,168,1,31,9,112) 150 BIN Data Connection 226 BIN Transfer Complete 157294592 bytes received in 14 seconds (1.1e+04 Kbytes/s) --主要需要设置为二进制传输模式,默认是ASCII方式的,可能会报错 ftp> quit 221 QUIT Goodbye.
这篇文章主要参考How to configure XDB for using ftp and http protocols with ASM [ID 357714.1],但是在自己试验过程中,发现文档中有些地方不太合适,这里做个补充说明:
1.ftp服务端不需要启动(这里只是用到了操作系统的ftp客户端功能,如果使用其他客户端工具,连操作系统客户端都省了)
2.dispatchers 中的SERVICE=
3.ftp和http两个功能,只需要配置一个即可(选择你需要的)
4.下图展示的是通过http方式访问结果(system用户登录)
发表在 Oracle ASM
一条评论