一次rman问题的处理
今天在进行例检的时候,发现dp在凌晨一点多的时候备份归档日志发生了一些错误,具体的rman报错为OB2BAR application on "XXXX02" successfully started.ob2rman.exe started with arguments:-backup -fullRecovery Manager: Release 9.2.0.6.0 - 64bit ProductionCopyright (c) 1995, 2002, Oracle Corporation. All rights reserved.RMAN> connected to target database: XXXX (DBID=169290886)RMAN> connected to recovery catalog databaseRMAN> RMAN> run {2> allocate channel 'dev_0' type 'sbt_tape'3>
linux查看处理器个数的方法
今天做设备验收,在查看cpu个数的时候,发现的一条命令[@more@]cat /proc/cpuinfo 1,processor 会从0开始记数 继续下去多个cpu2,flags 如果有 ht 说明支持超线程技术3,判断物理CPU的个数可以查看physical id 的值,相同则为同一个物理 CPU。下面是自己服务器上的cpuinfo文件的内容:processor : 0vendor_id : GenuineIntelcpu family : 15model : 4model name : Intel(R) Xeon(TM) CPU 3.00GHzstepping : 3cpu MHz : 3000.953cache size : 2048 KBphysical id : 3siblings
Rman Crosscheck删除失效归档
最近在做巡检的时候发现,有台数据库服务器归档日志备份经常会出现一些问题,"specification does not match any archive log in the recovery catalog",估计是arch目录中的文件名称和catalog中的文件名称有差异.所以此时需要手工执行crosscheck过程,之后Rman备份可以恢复正常.[@more@]1.连接数据库rman target / catalog rman/rman@fjrman --> 在db01上连接dp的备份数据库.fjrman为备份数据库的连接串2.Crosscheck日志RMAN> crosscheck archivelog all;configuration for SBT_TAPE channel 2 is ignoredconfiguration f