20081031---海南联通工作内容
海口，一个空气极其清新，气候很宜人的城市，迫不及待的换掉了长衣裤，穿上了短裤、短袖。
城西路金宝来酒店，协议价168；实际入住南海大道蓝海阳光大酒店
1、主持和实施将华为路由器上架，并和现在的和总部路由器做冷备：
此项工作待定
2、主持和实施海南综合网管采集接口服务器双节点：
5、6，采集服务器，各自运行部分采集程序，需两台配置一样，各自运行一半、互为备份；
已经购置4块硬盘，做raid1，此项需要联系厂家确认，能否保持已有的数据。
做之前，需要备份已有的数据和配置信息
3、3510磁盘阵列配置到CLUSTER中：
目前已经做好物理连接，系统能看到，需要安装到cluster里面。
4、G网ORACLE数据库规划整理以及备份方案确定和配置：
*** G网的oracle已经安装，但是表空间未规划，不稳定，需要调整（C网的比较稳定）；
*** 无备份措施，nbu需要配置，部分策略已经配置，但是尚未正式运转；
-----------------------------------------------
20081103---到达海口，在海秀中路如家酒店住一晚
了解系统现状，32-C网数据库服务器、35-C网应用服务器、38-G网应用服务器
项目人员：王伟（聊城）、陈文伟（贵州）、万丽丽（咸阳）、宦文静（菏泽）
-------------------------------------------------
20081104---熟悉环境、配置电脑等，汗，这里网络比较特殊，新装了一个虚拟机，才可以上网。
晚餐要了一份文昌鸡套餐，不好吃，或许酒店的不正宗吧。力加啤酒，感觉一般。
感冒的症状似乎好转了，继续注意休息。
---------------------------------------------------
20081105---今天的目标，配置完nbu
自本周一0点开始，ora_cookdb_0_2的备份出现异常：Errors caused the user backup to fail.
需要首先解决此问题，再继续配置G网的nbu。
更详细的错误信息是：
media manager terminated during mount of media id W614L2, possible media mount timeout
media manager terminated by parent process
说明media id W614L2出问题，在mount的时候超时。
进而查看media log，发现10月16日，W614L2 removed from media manager databse (expired)
10月30日，W613L2 removed from media manager databse (expired)。
如果不做处理，或许以后与media 613相关的policy也会出错。
针对以上的更详尽的信息是：
-------------------start
Starting backup at 2008-11-05 02:33:12
channel ch00: starting incremental level 2 datafile backupset
channel ch00: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00008 name=/database/oradata/cookdb/idx.dbf
input datafile fno=00018 name=/database/oradata/cookdb/nms18.dbf
input datafile fno=00025 name=/database/oradata/cookdb/nms11.dbf
input datafile fno=00032 name=/database/oradata/cookdb/nms04.dbf
input datafile fno=00039 name=/database/oradata/cookdb/idx01.dbf
input datafile fno=00046 name=/database/oradata/cookdb/his11.dbf
input datafile fno=00053 name=/database/oradata/cookdb/his04.dbf
input datafile fno=00060 name=/database/oradata/cookdb/idx08.dbf
input datafile fno=00076 name=/database/oradata/cookdb/ALARM05.dbf
input datafile fno=00094 name=/database/oradata/cookdb/idx12.dbf
input datafile fno=00001 name=/database/oradata/cookdb/system01.dbf
input datafile fno=00083 name=/database/oradata/cookdb/BUREAU02.dbf
input datafile fno=00079 name=/database/oradata/cookdb/INDX2_02.dbf
input datafile fno=00092 name=/database/oradata/cookdb/JOBSCHEMA.dbf
input datafile fno=00071 name=/database/oradata/cookdb/EOMS04.dbf
input datafile fno=00003 name=/database/oradata/cookdb/cwmlite01.dbf
input datafile fno=00010 name=/database/oradata/cookdb/xdb01.dbf
channel ch00: starting piece 1 at 2008-11-05 02:33:21
channel ch01: starting incremental level 2 datafile backupset
channel ch01: specifying datafile(s) in backupset
input datafile fno=00102 name=/database/oradata/cookdb/idx13.dbf
input datafile fno=00011 name=/database/oradata/cookdb/nms25.dbf
input datafile fno=00017 name=/database/oradata/cookdb/nms19.dbf
input datafile fno=00024 name=/database/oradata/cookdb/nms12.dbf
input datafile fno=00031 name=/database/oradata/cookdb/nms05.dbf
input datafile fno=00038 name=/database/oradata/cookdb/idx02.dbf
input datafile fno=00045 name=/database/oradata/cookdb/his12.dbf
input datafile fno=00052 name=/database/oradata/cookdb/his05.dbf
input datafile fno=00059 name=/database/oradata/cookdb/idx07.dbf
input datafile fno=00075 name=/database/oradata/cookdb/ALARM04.dbf
input datafile fno=00093 name=/database/oradata/cookdb/idx11.dbf
input datafile fno=00112 name=/database/oradata/cookdb/NMSTBS04_1.dbf
input datafile fno=00085 name=/database/oradata/cookdb/RAWDATATBS02.dbf
input datafile fno=00007 name=/database/oradata/cookdb/tools01.dbf
input datafile fno=00070 name=/database/oradata/cookdb/EOMS03.dbf
input datafile fno=00115 name=/database/oradata/cookdb/RES_BAK01.dbf
channel ch01: starting piece 1 at 2008-11-05 02:33:21
released channel: ch00
released channel: ch01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch00 channel at 11/05/2008 03:49:17
ORA-19506: failed to create sequential file, name="bk_23042_1_669954798", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
VxBSACreateObject: Failed with error:
Server Status: Communication with the server has not been iniatated or the server status has not been retrieved from the server.
RMAN>
Recovery Manager complete.
Script /database/nbu/hot_database_backup.sh
==== ended in error on 2008年11月05日 星期三 05时04分44秒 CST ====
---------------------------end
oracle@hnora$oerr ora 19511
19511, 00000, "Error received from media manager layer, error text:\n %s"
// *Cause: An error occurred in the media management software which
// is linked with the Oracle server to perform backup and restore
// in cooperation with Recovery Manager.
// *Action: If the text of message 19511 does not provide enough
// information to resolve the problem, then you should contact the
// vendor of the media management software.
以上表明，可能是介质管理或介质本身除了问题。
需要先在管理界面确认，如必要，去带库那里看看。
结论：L25带库已经掉电，且无法供电，汗！！！
2008-11-5提交局方的进度计划。
1、关于G网oracle数据库备份方案：
由于需要先处理周一凌晨开始nbu备份错误，此项工作预计2天，本周五之前完成；
2、G网数据库配置优化、表空间规划：
预计需要三天，下周二之前完成；
3、采集、接口服务器双节点：
系统及数据备份、应用服务部署两天；
需要厂家先做完镜像
4、3510磁盘阵列配置到cluster中：
需联系厂家支持
以上3、4项工作可以与1、2并行开展，总体预计下周四完成。
---------------------------------------------------------------------
20081106---
ora9i是G网的数据库，用户是dyora
今天继续研读rman、nbu相关的文档，对于oracle备份、nbu逐步熟悉。
找到了一个实用的pdf生成工具，pdffactory，很好用。
----------------------------------------------------------------
20081107---
L25带库学习：
放置了10盘200G的磁带。volume pool目前C网使用的是netbackup pool。
bpadm、vmadm、bp是nbu三个基本的管理指令，gui是jnbSA、jbpSA。
今天需要出的文档是：G网的备份方案。---完成初稿。
---------------------------------------------------
20081108---
C网的0、2级备份策略是ora_cookdb_0_2，备份脚本是/database/nbu/hot_database_backup.sh
C网的1级备份策略是ora_cookdb_1，备份脚本是/database/nbu/hot_database_backup2.sh
以上两个脚本几乎完全一样，就差一个数字不一样(1->2)，呵呵
||
\/
G网的0、2级备份策略是ora_ora9i_0_2，备份脚本是/netwatcher/performance/dayongdb/nbu/hot_database_backup.sh
G网的1级备份策略是ora_ora9i_1，备份脚本是/netwatcher/performance/dayongdb/nbu/hot_database_backup2.sh
需要明确volume pool用哪一个？G网使用的是NetBackup池，共7盘磁带，还有一个other池2盘磁带，一个Test池1盘磁带。
C网与G网公用一个池够用吗？需要确认数据库的大小，不过考虑到安全、独立性，建议使用单独的卷池。
----------------------------------------
20081109---
目前C网的数据库裸数据大小是：3.4808E+11约348G
实际数据文件和日志文件大小是：约421G
G网的数据库裸数据大小是：6.1540E+10约62G
实际数据文件和日志文件大小是：约124G
由于磁带的数目有限计12盘。
---------------------------------------------
20081110---关于G网数据库的配置、调整
数据库的优化，需从多方面入手。
关于nbu，实际又配置了other卷池，把netbackup卷池的613磁带配置到了other卷池，这样other卷池使用了3盘磁带600G，应该暂时够用了，以后可以根据具体情况重新调整卷池，比如把netbackup卷池的不用的磁带change到other卷池。
oratmn用户执行环境变量setenvora，是所有的tuxedo应用。
实际更改数据库归档模式过程：
1、关闭oratmn用户的tuxedo服务；91个process
2、关闭10.21.9.1的资源管理服务；
3、关闭10.21.0.41的weblogic服务；
4、数据库归档模式修改：
SQL> create spfile from pfile;
File created.
SQL> startup mount
ORACLE instance started.
Total System Global Area 2451541056 bytes
Fixed Size 732224 bytes
Variable Size 973078528 bytes
Database Buffers 1476395008 bytes
Redo Buffers 1335296 bytes
Database mounted.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /netwatcher/perf-data/lcora/archive
Oldest online log sequence 7272
Current log sequence 7273
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /netwatcher/perf-data/lcora/archive
Oldest online log sequence 7272
Next log sequence to archive 7273
Current log sequence 7273
SQL>
归档模式修改成功！
5、启动oratmn用户的tuxedo服务；91个process
6、启动41的权限管理；
7、启动10.21.9.1的资源管理服务；
-------------------------------------------------
20081111---
今天完成了《海南联通G网oracle数据库备份方案.pdf》，提交项目。
-------------------------------------
20081112---今天订了周五晚间回济南的机票
观察NBU：昨晚自动做了一次2级备份，耗时40分钟，仍旧使用第一盘磁带W617L2。
晚间的2级备份持续了50分钟，使用哪盘磁带呢？明天看下。
（实际：仍旧使用第一盘磁带W617L2）
今天工作计划：
1、针对采集及接口服务器5、6的镜像工作，出一份详细的操作步骤；
2、G网数据库的调整、优化。
实际完成了《海南联通采集及接口服务器双节点实施方案200811.pdf》，并作了第一个节点的大部分实施工作。
------------------------------------------------
20081113---
今天继续部署其他的应用。
今天发现应用在某个目录下临时生成了超过20万个文件！汗，删除都很困难。
rm是不行了，find的方式：
find . -mtime +14 -exec rm {} \;
find . -mtime +14 | xargs rm
发现第一种方式效率太低，而第二种方式的效率比较高，意外ing
另外一个发现是，在上一级目录，直接rm -rR是可以的。
-------------------------------------------
20081114---
perl的安装出了问题：
HN-PER$perl -v
ld.so.1: perl: fatal: libc.so.1: version `SUNW_1.19' not found (required by file perl)
Killed
显示早期的solaris 7版本的系统库对于新版本的perl支持有问题，只能安装低版本的perl，比如5.0.
实际从oracle8的安装目录下找到了合适的perl版本，安装配置成功。
------------------------------------------------
20081115---周末需要备份两台机器
----------------------------------------------
关于G网数据库调整：
1、查看系统资源占用情况
hngora服务器的情况：
oracle@hngora$prtdiag|more
System Configuration: Sun Microsystems sun4u Sun Fire E4900
System clock frequency: 150 MHz
Memory size: 16384 Megabytes
========================= CPUs ===============================================
CPU Run E$ CPU CPU
FRU Name ID MHz MB Impl. Mask
---------- ------- ---- ---- ------- ----
/N0/SB4/P0 16,528 1050 16.0 US-IV 2.3
/N0/SB4/P1 17,529 1050 16.0 US-IV 2.3
/N0/SB4/P2 18,530 1050 16.0 US-IV 2.3
/N0/SB4/P3 19,531 1050 16.0 US-IV 2.3
oracle@hngora$sar -u 2 10
SunOS hngora 5.9 Generic_118558-26 sun4u 11/11/2008
09:28:27 %usr %sys %wio %idle
09:28:29 13 28 2 57
09:28:31 13 29 2 56
09:28:33 19 28 2 50
09:28:35 14 29 3 55
09:28:37 12 27 3 58
09:28:39 14 28 4 53
09:28:41 14 28 4 54
09:28:43 19 30 5 46
09:28:45 13 28 4 54
09:28:47 19 32 12 38
Average 15 29 4 52
由上可知，在现在这个时候，hngora服务器的CPU资源占用情况正常，%wio明确表示了系统是否存在io的问题，cpu等待io的百分比是4%，用户进程占用CPU百分比15%，系统进程29%，CPU空闲百分比52%，总体情况不错。
oracle@hngora$date
Tue Nov 11 10:05:57 CST 2008
oracle@hngora$sar -u 2 10
SunOS hngora 5.9 Generic_118558-26 sun4u 11/11/2008
10:06:07 %usr %sys %wio %idle
10:06:09 45 34 8 12
10:06:11 48 35 7 10
10:06:13 44 34 9 13
10:06:15 42 35 8 15
10:06:17 35 31 16 18
10:06:19 34 32 15 19
10:06:21 35 32 16 16
10:06:23 36 34 17 12
10:06:25 35 34 17 14
10:06:27 36 34 15 14
Average 39 34 13 14
oracle@hngora$
可见即使CPU比较繁忙的时候，也不是因为等待io造成的，就是说磁盘的io情况不错，是用户进程变化较大，不同的时段业务量变化较大造成系统的繁忙。
oracle@hngora$date
Tue Nov 11 10:08:56 CST 2008
oracle@hngora$sar -u 2 10
SunOS hngora 5.9 Generic_118558-26 sun4u 11/11/2008
10:09:00 %usr %sys %wio %idle
10:09:02 53 38 4 5
10:09:04 55 37 4 4
10:09:06 53 34 6 7
10:09:09 54 34 5 6
10:09:11 51 39 5 5
10:09:13 43 34 9 13
10:09:15 40 33 11 16
10:09:17 40 37 10 13
10:09:19 40 38 13 10
10:09:21 40 36 14 10
Average 47 36 8 9
oracle@hngora$
初步判断，现在是系统忙时，业务处理量较大。
做一个长时间段统计吧：
oracle@hngora$nohup sar -u 10 3600 > sar.txt&
晚上21：45，再次开始统计：
oracle@hngora$pwd
/opt/dyora/admin/ora9i
oracle@hngora$nohup sar -u 10 3600 > sar2.txt&
2、查看划给oracle使用的内存大小
SQL> show sga
Total System Global Area 2451541056 bytes
Fixed Size 732224 bytes
Variable Size 973078528 bytes
Database Buffers 1476395008 bytes
Redo Buffers 1335296 bytes
SQL>
文章评论