linux下挂载移动硬盘
新建设的DATAGUARD数据库，主库早上某表空间增加数据裸设备rdata91_disk作为数据文件后从库应用日志失败。 经查因为standby_file_management状态非AUTO引起。
SQLLDR应用举例【转】 1、普通装载 LOAD DATA INFILE *
故障现象：A中的存储过程编译提示权限错误 Error: PL/SQL: ORA-01031: insufficient privileges 通过模糊授权不管用，最后对B用户授予DBA后用B用户登录对A授权后A中的存储过程即可正常编译。 SQL> grant dba to dg_write; Grant succeeded
错误内容：<BEA-090782> <Server is Running in Production Mode and Native Library(terminalio) to read the password securely from commandline is not found.>
为减轻核心数据库的负担，我们采用了逻辑STANDBY技术分离物理读对核心数据库的影响。但某报表应用方提出报表中采用了大量的中间表，通常是把基础数据运算后存入中间表，然后报表读中间表进行展现。要彻底解决该问题显然最好的办法是计算过程前推，即在应用插入基础数据的时候主动往报表所需要的数据插入运算数据，或者至少是接近报表的数据，否则即使后期采用中间表等来解决，也无法解决临时的运算带来的极大的IO开销。但应用方迫于人力和时间所限显然不敢短期内做彻底的优化，那么最后只有DBA开刀，对逻辑STANDBY启动写入功能，即用新建表写入数据。显然这增加了逻辑STANDBY的后期可维护性，但相对于减轻主库的压力来讲，我们的DBA还是宁可牺牲些个人的时间。
RAC实施FLASHBACK要点： 1、要有共享存储（ASM等），不能本地文件或者裸设备 2、要闪回表必须对表ROW MOVEMENT
占位中
故障描述：两台机器都可以PING通。处于STANDBY状态的LTM可以通过浏览器正常登录，但处于ACTIVE的LTM却无法通过浏览器登陆，导致服务器负载均衡状态无法查看，更有甚者通过SSH连接CONSOLE命令行也无法登陆（提示Connection refused），通过两台机器的心跳地址可以PING通，但还是无法用SSH建立连接（同样提示Connection refused），可诡异的是LTM应用分发居然正常。由于ACTIVE的主机无法登陆，这种情况下相当于服务器负载均衡失控，更要命的是无法完成ACTIVE和STANDBY的切换，因为Force To Standby按钮只有在ACTIVE的机器上才有。中午趁午休时间赶往IDC，但考虑到直接断点的风险决定先将就运行，同时准备一个极端的方案（在该F5出现问题时，考虑通过交换机屏蔽ACTIVE的机器进行强行切换）
故障现象： ERROR: 12-09-20 16:15:03 获取最大号时发生错误:CallableStatementCallback; uncategorized SQLException for SQL [{call USP_SYS_CMSCODE(?, ?, ?, ?)}]; SQL state [72000]; error code [1552]; ORA-01552: 非系统表空间 'USERS' 不能使用系统回退段 ORA-06512: 在 "WMP2.USP_SYS_CMSCODE", line 24 ORA-06512: 在 "WMP2.USP_SYS_CMSCODE", line 31
故障现象：客户某台WINDOWS服务器掉电，ORACLE数据库STARTUP提示控制文件CONTROL01.CTL、CONTROL02.CTL被破坏。 一、处理控制文件异常故障 方法：直接拷贝CONTROL03.CTL到CONTROL01.CTL 二、尝试启动 1、startup，碰到ORA-01172、ORA-01151错误 SQL> startup;
周六晚上我们4个和1个外援按计划进行了实施。 实施时间窗口：晚20：00-上午6：00 通宵实施非常辛苦，机房的环境也比较恶劣，试想值班的大爷进去一个巡更就马不停蹄的转身就走，答曰里头空气太差。但愿我们能少一些实施，但为了确保少出问题，我们必须付出应用的代价。
今天上班监控系统报警某台AIX小机报告/var目录使用94%以上（我们的阀值是85%）。 Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/hd9var 1.00 0.07 94% 1132 7% /var 通过du -s /var/* | sort -rn | head命令对/var/下的文件按大小进行了排序，发现是/var/adm/目录导致，再一看是个wtmp文件达到了近1G。
回想笔者读书那会还不都是趴在桌上,间或有几个胆大的能够拼桌子躺着。小学都是不行好几公里上学，无论刮风下雨。初中便要住校了，大伙都是一罐霉干菜或者咸菜过来的，但大伙比成绩高的劲头可足了。高中条件好很多了，不也是趴着午睡么。还指望读书要有多好的条件呀，那会每顿能吃好已经非常满意了。甚至知道现在有多少贫困地区的孩子连吃饭都成问题，有多少学校缺乏课桌…… 家长们是不是自己也该好好反省下，一提到吃饭就得营养午餐；一提到睡觉就想着标准间；一提到学习就要报补习班；一见到老师就得想办法巴结；到底是培养矫情的下一代还是怎么样？？
故障现象： Errors in file /home/oracle/admin/zjport/bdump/zjport_mrp0_17798.trc: ORA-01111: name for data file 19 is unknown - rename to correct file ORA-01110: data file 19: '/home/oracle/product/10.2.0/db_1/dbs/UNNAMED00019' ORA-01157: cannot identify/lock data file 19 - see DBWR trace file ORA-01111: name for data file 19 is unknown - rename to correct file ORA-01110: data file 19: '/home/oracle/product/10.2.0/db_1/dbs/UNNAMED00019' Wed Sep 5 11:10:08 2012 MRP0: Background Media R
今年以来进行了若干次的通宵实施，昨天又去了IDC，进行了通宵前的踩点工作，接下来就是连续两个周末的通宵实施。连IDC的看门大爷都说我们特别能吃苦，特别肯干。说实话还不是为了平时能多清闲些呢，“平时多流汗，战时少流血”。实施中还是有些小插曲，先是网线松动导致专网接入异常，后来又是网线松动导致公网接入和接入交换机间一个线不通，还好确认充分，也进一步确认了接下来两周网线整理的必要性。
研究解决CLOB字段IO问题的方法
系统环境：REDHAT LINUX5.4 + ORACLE10.2.0.4，是通过虚拟机复制另外一台数据库系统环境后安装ORACLE获得。 故障现象：ORACLE安装正常，本地服务正常，本地数据通过IMP可以正常导入，但是LSNRCTL能够启动，但我们要的port服务未能正常监听。
有个周末只有的JOB，目的是迁移4千万数据，跑了一宿都没跑完。无奈业务高峰到了，尝试KILL掉，可是做了如下动作居然杀了又起，多次反复，还在RAC两个节点中转移，最后无奈把其调用的存储过程改成NULL过了一会ORACLE才罢休，跑了一会ORACLE就不跑了。
declare jobno number; begin dbms_job.submit( jobno, 'dba_bas_ent_workflow_clear;', --what to_date('19-08-2012 23:00:00', 'dd-mm-yyyy hh24:mi:ss'), interval => 'TRUNC(next_day(sysdate,1))+23/24'); commit; end;
场景： 业务部门要求导入一批数据，是CSV格式的，大家就想到了EXCEL格式可以打开，但悲剧的是该批数据超过10万条，用EXCEL处理显然行不通，更悲剧的是打开直接就是乱码。于是笔者接了单子，筹划用SQLLDR进行导入。话说7年前做野村证券的BATCH系统时大量的使用了UNIX SHELL调用ORACLE SQLLDR功能，但若干年没用了居然对预防有些生疏。
以下存储过程编译正常，其中的SQL语句在PLSQL执行也正常，但是在存储过程中执行即报告错误：ORA-01031: insufficient privileges。 create or replace procedure DBA_REBUILD_INDEX As Begin execute immediate 'alter index PK_DUBAI_STORAGE_OUT_MANIFEST rebuild online'; execute immediate 'alter index WATERGAUGE_PK rebuild online'; Return; end DBA_REBUILD_INDEX;
故障现象：逻辑STANDBY数据库注册日志成功，但应用日志出现错误，提示“ORA-00368: checksum error in redo log block”，显然是文件受到了破坏。 Tue Jul 24 08:25:59 2012 LOGMINER: WARNING: error 368 encountered, failed to read corrupt logfile /archivelog/lstandbyarch_2_27774_614088933.arc Tue Jul 24 08:25:59 2012 Errors in file /home/oracle/admin/lstandby/bdump/lstandby_p000_229718.trc: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 70144 change 4885842900 time 07/21/2012 22:03:20 ORA-00334: archived log: '/
背景：DG数据库，因为有大版本发布表结构变动很大，为把从库作灾备环境，主动停掉了主库和DG间的同步。可是周日主库来了个全库备份，之后删除了所有的归档。在从库重新同步是报告GAP，缺失归档达50个。想到采用RESTORE ARCHIVELOG恢复归档，可以前就用过单个归档，先是猜语法试验了几次不成功，无奈查文档确认语法后实施成功。神奇的是我归档恢复到的是一个自己定义的目录，归档恢复后从库居然直接从那个目录同步过去了，ORACLE真是省心。
今天ADDM巡检发现出现问题：Finding The throughput of the I/O subsystem was significantly lower than expected 该问题从来未出现过，立即引起笔者的警觉，展开如下相关项发现多个裸设备同时出现IO异常的告警，而按笔者所在的业务系统，该时段显然未进入一天的业务最高锋，而这个问题是以往哪怕是节前最高峰也从未出现的。马上要求系统工程师确认存储子系统有无问题，答复是“远程管理口未接上”。当天下班后笔者强烈的直觉感觉到可能存在存储异常状况，决定前往IDC机房巡检查看存储系统。到IDC居然发现由于临时太急，存储的钥匙也未带上，后通过存储柜门的小孔透视发现一块磁盘亮黄灯。于是立即向系统工程师反馈这一故障，当然我们的存储由于RAID+HOTSPARE结构,即使坏两块盘也不丢数据。 最后分析应该是该块磁盘故障导致IO临时异常，提醒大家,ADDM中观测到大量的裸设备或文件系统异常时一定要关注磁盘有无异常状况。
故障现象： 逻辑DG数据库日志能够应用，但是确不会将应用后的日志删除，查看日志发现已经自动设置了TURNING OFF LOG AUTO DELETE 故障处理1：尝试重启，未解决问题 Attempt to start background Logical Standby process LOGSTDBY Parameter: LOG_AUTO_DELETE = FALSE LOGSTDBY Parameter: DISABLE_APPLY_DELAY = LOGSTDBY Parameter: REAL_TIME = 故障处理2：直接设置参数解决该问题 EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'TRUE');
问题现象：逻辑DG日志未应用处理。 通过Select * From v$logstdby 发现存在等待日志ORA-16240: Waiting for logfile (thread# 2, sequence# 25793) 问题原因：逻辑DG备库归档目录满
个人笔记:别忘记crs的LOG目录，有时候会很大
SQL> alter system set log_archive_dest_1='LOCATION= /archivelog'; alter system set log_archive_dest_1='LOCATION= /archivelog' * ERROR at line 1: ORA-32017: failure in updating SPFILE ORA-16179: incremental changes to "log_archive_dest_1" not allowed with SPFILE
Linux、AIX上都提供了History命令，可以查询以前执行的命令历史记录，但是这个记录并不包含时间项目。 有时候需要回溯源头时比较郁闷，如何让History记录时间呢？如下针对LINXU和AIX进行了实践，本文本意是作为个人记录！
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
