本来也是不知道今天metalink会换脸的，只是下午遇到过ora-600 [2022] 的问题的时候，登录了metalink准备查资料，发现login的界面已经换了，默认是登录新版的metalink。当然，你也可以选择classic登录老版的metakink。 对于这个变化，好多dba朋友已经感受到 […]
Google Chrome遭遇SPA崩溃
昨天晚上google的浏览器Chrome 放出来了，兴冲冲的下载来试了一下，发现打开就立即崩溃： 后来在公司的论坛上看到高人指点，原来是和公司的网络终端软件SPA（Symantec Protection Agent）有冲突。用下面的方法即可解决： [crayon-6906549e4964e30543 […]
谨慎的使用shutdown abort
今天在重启一个库的时候，由于等了超过半小时，仍然没有完成数据库的close，于是就用shutdown abort命令关闭数据库。但是在起来的时候，发现在alertlog中有大量的SMON的报错，而且还在持续不断的报错出来。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 |
<--- 正常的启动信息 begin here ---> Mon Sep 1 16:32:02 2008 Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 1 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: 9.2.0.6.0. System parameters with non-default values: processes = 1200 timed_statistics = TRUE shared_pool_size = 419430400 sga_max_size = 2108652208 large_pool_size = 117440512 java_pool_size = 117440512 spfile = /dev/vg_ora01/rspfile_128m_01 control_files = /dev/vg_ora01/rctrl_128m_01, /dev/vg_ora02/rctrl_128m_02 db_block_size = 8192 db_cache_size = 1258291200 compatible = 9.2.0.0.0 log_archive_start = TRUE log_archive_dest_1 = location=/arch log_archive_format = arch_%t_%s.arc log_buffer = 10485760 db_files = 800 db_file_multiblock_read_count= 16 fast_start_mttr_target = 300 undo_management = AUTO undo_tablespace = UNDOTBS1 undo_suppress_errors = TRUE undo_retention = 10800 remote_login_passwordfile= EXCLUSIVE db_domain = instance_name = gdmocs job_queue_processes = 6 hash_join_enabled = TRUE background_dump_dest = /oracle/app/oracle/admin/gdmocs/bdump user_dump_dest = /oracle/app/oracle/admin/gdmocs/udump core_dump_dest = /oracle/app/oracle/admin/gdmocs/cdump sort_area_size = 524288 db_name = gdmocs open_cursors = 500 star_transformation_enabled= FALSE query_rewrite_enabled = TRUE pga_aggregate_target = 524288000 PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 RECO started with pid=7 CJQ0 started with pid=8 Mon Sep 1 16:32:03 2008 ARCH: STARTING ARCH PROCESSES ARC0 started with pid=9 ARC0: Archival started ARC1 started with pid=10 ARC1: Archival started Mon Sep 1 16:32:03 2008 ARCH: STARTING ARCH PROCESSES COMPLETE Mon Sep 1 16:32:03 2008 ARC1: Thread not mounted Mon Sep 1 16:32:03 2008 ARC0: Thread not mounted Mon Sep 1 16:32:03 2008 ALTER DATABASE MOUNT Mon Sep 1 16:32:07 2008 Successful mount of redo thread 1, with mount id 2193310019 Mon Sep 1 16:32:07 2008 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Mon Sep 1 16:32:07 2008 <--- 正常的启动信息 end here ---> <--- 开始打开数据，发现需要做实例恢复 begin here ---> ALTER DATABASE OPEN Mon Sep 1 16:32:08 2008 Beginning crash recovery of 1 threads Mon Sep 1 16:32:08 2008 Started redo scan Mon Sep 1 16:32:09 2008 Completed redo scan 27274 redo blocks read, 46702 data blocks need recovery Mon Sep 1 16:35:20 2008 <--- 开始打开数据，发现需要做实例恢复 end ---> <--- 开始实例恢复 ---> Started recovery at Thread 1: logseq 24462, block 231548, scn 0.0 Mon Sep 1 16:35:20 2008 Recovery of Online Redo Log: Thread 1 Group 1 Seq 24462 Reading mem 0 Mem# 0 errs 0: /dev/vg_ora01/rredo_256m_01 Mem# 1 errs 0: /dev/vg_ora02/rredo_256m_11 Mon Sep 1 16:35:22 2008 Completed redo application Mon Sep 1 16:35:32 2008 Ended recovery at Thread 1: logseq 24462, block 258822, scn 13.3684259989 46702 data blocks read, 46201 data blocks written, 27274 redo blocks read Crash recovery completed successfully Mon Sep 1 16:35:33 2008 LGWR: Primary database is in CLUSTER CONSISTENT mode Thread 1 advanced to log sequence 24463 Thread 1 opened at log sequence 24463 Current log# 3 seq# 24463 mem# 0: /dev/vg_ora01/rredo_256m_03 Current log# 3 seq# 24463 mem# 1: /dev/vg_ora02/rredo_256m_13 Successful open of redo thread 1 Mon Sep 1 16:35:33 2008 <--- 开始前滚 ---> SMON: enabling cache recovery Mon Sep 1 16:35:33 2008 ARC0: Evaluating archive log 1 thread 1 sequence 24462 ARC0: Beginning to archive log 1 thread 1 sequence 24462 Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/arch_1_24462.arc' Mon Sep 1 16:35:34 2008 Successfully onlined Undo Tablespace 1. Mon Sep 1 16:35:34 2008 <--- 开始回滚 ---> SMON: enabling tx recovery Mon Sep 1 16:35:34 2008 Database Characterset is ZHS16GBK Mon Sep 1 16:35:34 2008 <--- 开始出现大量的SMON报错 ---> SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available Mon Sep 1 16:35:35 2008 replication_dependency_tracking turned off (no async multimaster replication found) Mon Sep 1 16:35:35 2008 SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available <--- 实例恢复完成，数据库open ---> Mon Sep 1 16:35:35 2008 Completed: ALTER DATABASE OPEN Mon Sep 1 16:35:35 2008 SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available SMON: about to recover undo segment 60 SMON: mark undo segment 60 as available |
此时，数据 […]
不要删除你所有的归档日志
今天遇到一个问题，同事来说归档目录已经全部删除了，但是归档目录的大小还是100%，且执行shutdown immediate挂死。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 262144 181520 80040 69% / /dev/vg00/lvol1 314736 84360 198896 30% /stand /dev/vg00/lvol8 4718592 1056280 3633752 23% /var /dev/vg00/lvol7 2654208 1435160 1209576 54% /usr /dev/vg00/lvol4 1540096 1028512 508264 67% /tmp /dev/vg00/lvol9 10485760 4948670 5365096 48% /oracle /dev/vg00/lvol6 94208000 7317328 86211936 8% /opt /dev/vg00/lvol5 163840 2480 160104 2% /home /dev/vg00/lv_arch 51216384 51112984 102632 100% /arch $ cd /arch $ ll total 0 drwxr-xr-x 2 oracle dba 96 Dec 18 2007 lost+found $ |
同时alertlog中也在不断的报错：
|
1 2 3 4 5 |
ORA-16014: log 2 sequence# 28801 not archived, no available destinations ORA-00312: online log 2 thread 1: '/dev/vg_audit01/rredo_128m_02' ORA-00312: online log 2 thread 1: '/dev/vg_audit01/rredo_128m_12' ORA-00312: online log 2 thread 1: '/dev/vg_audit01/rredo_128m_22' Mon Sep 1 10:28:55 2008 |
HP中无法使用@符号
在一次测试中，发现在oracle用户下无法使用@符号，测试用tnsnames登录的时候，无法识别@符号：
|
1 2 |
$ sqlplus user/pwd@hnadt sh: hnadt: not found. |
但是tnsping却能ping通的，检查tnsnames.ora文件也没问题，同时，用vi打开profile时，也不能添加使用@ […]
小议compress表
总体说来，compress table的原理和compress index原理大致相同，compress table是压缩某表的同一字段下的相同的行，compress index是压缩复合索引中同一字段（一般是第一、二个字段）的相同行。 compress表可以通过user_tables.COMPRE […]
oracle的整合力量
1、7月15日，oracle在亚太区甲骨文融合中间件新策略发布会上，首次披露并购整合BEA后的策略。该战略涵盖BEA和已有oracle融合中间件的产品线，将保留并支持BEA产品线。顶级的BEA销售人员、开发人员将被保留，原BEA中国公司将占oracle中国管理团队较大比重，原BEA全球副总裁兼中国区 […]
开启异步IO的相关风险
由于IO的请求不是每次等待完成指令后再发送下一个请求，而是存在于队列中，且遵循FIFO。因此如果遇到存储掉电的情况，就可能会出现数据的不一致。虽然这种情况出现的可能性不大，因为存储中有电池，能保证cache中的信息写到存储中。但是在这里还是提一下数据丢失的风险。 由于我们的异步IO的队列中是针对使用 […]
远程rac，比较难
下面的2张图是做远程rac（RAC on Extended Distance Clusters）的2种模式： 前者是host base的模式，近端数据库节点在读写的时候，同时读写近端和远端的存储，近端和远端的存储中的内容都是一模一样的；远端数据库节点在读写的时候也是一样，同时读写近端和远端的存储。这 […]
分布式事务故障处理
分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过dblink update远程数据库的一行记录，如果在执行过程中网络异常，或者其他事件导致本地数据库无法得知远程数据库的执行情况，此时就会发生in doublt的报错。此时需要dba介入 […]
10g的新进程以及not documented进程
昨天在群里面有人问到，10g的rac中 ora_pz99是啥进程，一开始也没查到资料，经朋友指点后，在metalink上找到了答案，原来这是属于not document的10g后台进程。在这里，干脆把10g新增的进程整理一下吧。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for Linux: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production SQL> !ps -ef |grep ora_ oracle 6296 1 0 Jul23 ? 00:00:07 ora_pmon_devdb1 oracle 6304 1 0 Jul23 ? 00:00:18 ora_diag_devdb1 oracle 6310 1 0 Jul23 ? 00:00:02 ora_psp0_devdb1 oracle 6315 1 0 Jul23 ? 00:01:26 ora_lmon_devdb1 oracle 6317 1 0 Jul23 ? 00:01:41 ora_lmd0_devdb1 oracle 6319 1 1 Jul23 ? 00:03:28 ora_lms0_devdb1 oracle 6329 1 0 Jul23 ? 00:00:01 ora_mman_devdb1 oracle 6331 1 0 Jul23 ? 00:00:07 ora_dbw0_devdb1 oracle 6333 1 0 Jul23 ? 00:00:15 ora_lgwr_devdb1 oracle 6337 1 0 Jul23 ? 00:00:15 ora_ckpt_devdb1 oracle 6341 1 0 Jul23 ? 00:00:13 ora_smon_devdb1 oracle 6351 1 0 Jul23 ? 00:00:00 ora_reco_devdb1 oracle 6359 1 0 Jul23 ? 00:00:33 ora_cjq0_devdb1 oracle 6365 1 0 Jul23 ? 00:00:18 ora_mmon_devdb1 oracle 6370 1 0 Jul23 ? 00:00:11 ora_mmnl_devdb1 oracle 6372 1 0 Jul23 ? 00:00:00 ora_d000_devdb1 oracle 6374 1 0 Jul23 ? 00:00:00 ora_s000_devdb1 oracle 6394 1 0 Jul23 ? 00:00:29 ora_lck0_devdb1 oracle 6422 1 0 Jul23 ? 00:00:01 ora_asmb_devdb1 oracle 6437 1 0 Jul23 ? 00:00:01 ora_rbal_devdb1 oracle 6840 1 0 Jul23 ? 00:00:01 ora_arc0_devdb1 oracle 6842 1 0 Jul23 ? 00:00:03 ora_arc1_devdb1 oracle 6895 1 0 Jul23 ? 00:00:01 ora_qmnc_devdb1 oracle 6916 1 0 Jul23 ? 00:00:00 ora_o003_devdb1 oracle 7065 1 0 Jul23 ? 00:00:00 ora_q001_devdb1 oracle 5327 1 0 Jul23 ? 00:00:30 ora_pz99_devdb1 oracle 16365 1 1 Jul23 ? 00:01:19 ora_j000_devdb1 oracle 23522 1 0 00:58 ? 00:00:00 ora_q002_devdb1 oracle 25680 1 0 01:00 ? 00:00:00 ora_q000_devdb1 oracle 26024 25845 0 01:00 pts/2 00:00:00 /bin/ksh -c ps -ef |grep ora_ oracle 26026 26024 0 01:00 pts/2 00:00:00 grep ora_ SQL> |
10 […]
关闭侦听须谨慎
侦听的关闭需要绝对的小心，因为在9i中，如果没有设置密码，侦听能轻易的关闭远程的侦听。有时候，生产库的侦听被宕不是因为被黑客入侵了，而是错误的操作而已。最近就遇到了这样的事情： 一次工程迁移，需要将原来的两台rp 4440换成两台rp 8440（有两台，是因为要做MC双机热备）。 当前网络情况： 主 […]