南望阿方小站

在买到外国商品时有时不知道哪里生产的，除了看made in xxx以后， 还可以根据条形码查询，以下是从网上找到的全球厂商条形码的前三位

各编码组织所在国家（地区）             前缀码 各编码组织所在国家（地区）
00—13 美国和加拿大                     609 毛里求斯
20—29 店内码（对无条码商品自行编码）   611 摩洛哥
30—37 法国                             613 阿尔及利亚
380 保加利亚                           619 突尼斯
383 斯洛文尼亚                         622 埃及
385 克罗地亚                           625 约旦
387 波黑                               626 伊朗
400—440 德国                           64 芬兰
45、49 日本                            690—695 中国
460—469 俄罗斯联邦                     70 挪威
471 中国台湾                           729 以色列
474 爱沙尼亚                           73 瑞典
475 拉脱维亚                           740 危地马拉
477 立陶宛                             741 萨尔瓦多
479 斯里兰卡                           742、744 洪都拉斯、哥斯达黎加
480 菲律宾                             743 尼加拉瓜
481 白俄罗斯                           745 巴拿马
482 乌克兰                             746 多米尼加
484 摩尔多瓦                           750 墨西哥
485 亚美尼亚                           759 委内瑞拉
486 格鲁吉亚                            76 瑞士
487 哈萨克斯坦                         770 哥伦比亚
489 中国香港                           773 乌拉圭
50 英国                                775 秘鲁
520 希腊                               777 玻利维亚
528 黎巴嫩                             779 阿根廷
529 塞浦路斯                           780 智利
531 马其顿                             784 巴拉圭
535 马耳他                             786 厄瓜多尔
539 爱尔兰                             789 巴西
54 比利时和卢森堡                      80—83 意大利
560 葡萄牙                             84 西班牙
569 冰岛                               850 古巴
57 丹麦                                858 斯洛伐克
590 波兰                               859 捷克
594 罗马尼亚                           860 南斯拉夫
599 匈牙利                             869 土耳其
600—601 南非                           893 越南
87 荷兰                                899 印度尼西亚
880 韩国                               90、91 奥地利
885 泰国                               93 澳大利亚
888 新加坡                             94 新西兰
890 印度                               955 马来西亚

–The End–

今天打算使用DBMS_Logmnr包恢复些数据看看，不过归档日志在RMAN备份完后被删除了。我用DBMS_Logmnr分析备份的归档文件时报错。

SQL> exec dbms_logmnr.add_logfile(’/u02/rman/arch_db1_20090624_29_1′,DBMS_LOGMNR.NEW);
BEGIN dbms_logmnr.add_logfile(’/u02/rman/arch_db1_20090624_29_1′,DBMS_LOGMNR.NEW); END;

*
ERROR at line 1:
ORA-01284: file /u02/rman/arch_db1_20090624_29_1 cannot be opened
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: /u02/rman/arch_db1_20090624_29_1
ORA-06512: at "SYS.DBMS_LOGMNR", line 68
ORA-06512: at line 1

看来Logmnr是无法识别备文件的，只有把归档文件从备份文件中还原出来才可以。查了下文档，用RMAN是可以搞定的。

RMAN> run
2> {
3> SET ARCHIVELOG DESTINATION TO ‘/u02/archive’;
4> restore archivelog sequence between 65 and 67;
5> }

executing command: SET ARCHIVELOG DESTINATION
using target database control file instead of recovery catalog

Starting restore at 24-JUN-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=142 devtype=DISK

channel ORA_DISK_1: starting archive log restore to user-specified destination
archive log destination=/u02/archive
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=65
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=66
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=67
channel ORA_DISK_1: reading from backup piece /u02/rman/arch_db1_20090624_29_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/rman/arch_db1_20090624_29_1 tag=TAG20090624T154331
channel ORA_DISK_1: restore complete, elapsed time: 00:00:27
Finished restore at 24-JUN-09

这样就在目录/u02/archive里还原了65-67三个序号的归档文件。接着就可以用DBMS_Logmnr分析日志了。

exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_65.dbf’,DBMS_LOGMNR.NEW);
exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_66.dbf’,DBMS_LOGMNR.addfile);
exec dbms_logmnr.add_logfile(’/u02/archive/arch_1_67.dbf’,DBMS_LOGMNR.addfile);

begin
dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
end;

select * from v$logmnr_contents

–The End–

终于自己申请了个域名，下载了个WP开博客了。

因为站太小，几乎没有外部链接会连进来，为了能想搜索引擎光顾自己的博客，可以自己到搜索引擎上去注册，注册过程是免费的。

Google的注册地址
http://www.google.com/addurl.html

Baidu的注册地址
http://www.baidu.com/search/url_submit.html

–The End–

今天查看RMAN备份的日志，发现里面有报错，进一步查看是RMAN在删除过期备份时报的错。错误信息如下。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of delete command on ORA_DISK_1 channel at 06/19/2009 09:15:55
ORA-19587: error occurred reading 16384 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1

看到这个消息，首先想会不会是硬盘有问题了。因不是删除文件，所以不会是空间满了。查看硬盘状况，还有很大的剩余空间。

于是打开trace进入RMAN

$ rman target = / trace rman.trc debug

Recovery Manager: Release 10.2.0.4.0 – Production on Fri Jun 19 14:01:16 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

RMAN-06005: connected to target database: PAYMENT (DBID=938111124)

RMAN> list copy;

RMAN-06009: using target database control file instead of recovery catalog
RMAN-20242: specification does not match any archive log in the recovery catalog
RMAN-06365: List of Control File Copies
RMAN-06366: Key     S Completion Time Ckp SCN    Ckp Time        Name
RMAN-06367: ——- – ————— ———- ————— —-
RMAN-06368: 36      A 19-JUN-09       44248899   19-JUN-09       /u02/oradata/rman/backup/2009-06-19/control.bak
RMAN-06368: 35      A 18-JUN-09       41511256   18-JUN-09       /u02/oradata/rman/backup/2009-06-18/control.bak
RMAN-06368: 34      A 17-JUN-09       39981536   17-JUN-09       /u02/oradata/rman/backup/2009-06-17/control.bak
RMAN-06368: 33      A 16-JUN-09       39213838   16-JUN-09       /u02/oradata/rman/backup/2009-06-16/control.bak

RMAN> crosscheck copy;

RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08605: channel ORA_DISK_1: sid=1134 instance=payment1 devtype=DISK
RMAN-20242: specification does not match any archive log in the recovery catalog
RMAN-06156: validation succeeded for control file copy
RMAN-08516: control file copy filename=/u02/oradata/rman/backup/2009-06-19/control.bak recid=36 stamp=689937350
RMAN-06156: validation succeeded for control file copy
RMAN-08516: control file copy filename=/u02/oradata/rman/backup/2009-06-18/control.bak recid=35 stamp=689850796
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of crosscheck command on ORA_DISK_1 channel at 06/19/2009 14:01:50
ORA-19587: error occurred reading 16384 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1

RMAN> exit

发现在查检 /u02/oradata/rman/backup/2009-06-17/control.bak 时中断报错了。打开rman.trc，也的确在检查 /u02/oradata/rman/backup/2009-06-17/control.bak 文件处报ORA-19587

……
DBGPLSQL:   channel ORA_DISK_1:  processing (file/handle=/u02/oradata/rman/backup/2009-06-17/control.bak,recid=34, old_status=A, hdl_isdisk=0, devicetype=DISK) [14:01:49.998] (change)
DBGPLSQL:   channel ORA_DISK_1:  force: 0 [14:01:49.998] (change)
DBGRPC:     krmxrpc: xc=182924940192 kpurpc2 rc=19587 db=target proc=DBMS_BACKUP_RESTORE.VALIDATEDATAFILECOPY
DBGRPC:     krmxrpc: xc=182924940192 chid=ORA_DISK_1 increment rpc count=8
DBGMISC:    krmqexe: unhandled exception on channel ORA_DISK_1 [14:01:50.004]
DBGMISC:    error recovery releasing channel resources [14:01:50.004]
……

查看大小，发现是0字节

$ ls -lh /u02/oradata/rman/backup/2009-06-17/control.bak
-rw-r–r–  1 oracle oinstall 0 Jun 19 14:00 /u02/oradata/rman/backup/2009-06-17/control.bak

把这个文件删除，再执行crosscheck copy;就正常了。

–The End–

Windows和Linux之间文件共享主要有两类方法，一类是使用Windows共享文件的协议，Linux下需要使用SAMBA；另一类是使用Linux共享协议，Windows需要安装支持NFS协议的软件。
因为通常发行版Linux里自带SAMBA，所以用SAMBA还是比较方便的，不过对于有些Linux系统，特别是一些嵌入式Linux系统，因为没有SAMBA，不过NFS还是支持的，这时如果想访问Windows共享文件，只能使Windows支持NFS协议了。
在Windows上安装NFS协议的软件有
SFU：微软出的，好像免费了，只是文件太大，没下载。
omni-nfs:文件不到10M，收费。
HummingBird nfs：好像也收费
nfsAXE：收费

–The End–