>>加入我的读者群 |《深入浅出Oracle》的购买途径 | Eygle.com两周年庆

March 17, 2010

在数据库历史上最重要的人物简介

埃德加·考特（EdgarF.Codd）

　　计算机界公认的关系数据库之父。1970年他提出了关系模型的理论，1970年以后，E.F.Codd继续完善和发展关系理论；之后创办了一个研究所The RelationalInstitute和一个公司Codd & Associations；1990 年出版了专著The Relational Modelfor Database Management：Version 2
　　E.F.Codd 以其对关系数据库的卓越贡献获得了1983 年ACM图灵奖。

　　C.J.戴特(C.J.Date)
　　C.J.Date 是最早认识到Codd 在关系模型方面所做的开创性贡献的学者之一，他是关系数据库技术领域中非常著名的独立撰稿人、学者和顾问，他使得关系模型的概念普及化。他参与了IBM公司的SQL/DS和DB2两大产品的技术规划和设计。30多年来，Date 一直活跃在数据库领域中，其著作有《数据库系统导论》，《对象关系数据库基础：第三次宣言》（1998）等。

　吉姆·格雷（Jim Gray）

　　Jim Gray使关系模型的技术实用化，他为RDBMS成熟并顺利进入市场起到了关键性的作用。他在事务处理方面取得了突出的贡献，使他成为该技术领域公认的权威，他也成为图灵奖诞生32 年来第三位在数据库技术的发展中作出重大贡献而获此殊荣的学者。曾参与主持过IMS、System R、SQL/DS、DB2等项目的开发。他的研究成果反映在他发表的一系列论文和研究报告之中，最后结晶为一部厚厚的专著：Transaction Processing: Concepts andTechniques。

　　Michael Stonebraker

　　Michael Stonebraker是Ingres的创始人。他是加州大学伯克利分校的教授，著名的数据库学者，他在1992 年提出对象关系数据库模型。S t o n e b r a k e r 教授领导了称为Postgres 的后Ingres 项目。这个项目的成果是非常巨大的，在现代数据库的许多方面都做出的大量的贡献。Stonebraker 教授还做出了一件造福全人类的事情，那就是把Postgres 放在了BSD 版权的保护下。

　　Jeffrey D. Ullman

　　Jeffrey D. Ullman 是国际知名的数据库专家。现为斯坦福大学的Stanford W. Ascherman计算机科学教授。1996 年获得Sigmod 贡献奖和1998年Karl V. Karstrom 杰出教育家奖获得者。出版了多本数据库专著。

Posted by eygle at 9:15 PM | Permalink | Comments (0) | 人物传奇 (28)

January 6, 2010

Office:试图运行的函数包含有宏或需要宏..

今天Office遇到了这个问题，参考如下方案得以解决：

在安装OFFICE2007 、2010 时，如选择不安装共享功能，打开WORD时就会出现"你正在试图运行的函数包含有宏或需要宏语言支持的内容，而在安装此软件时，您（或您的管理员）选择了不安装宏或控件的支持功能"。

解决方法1:

XP系统：在word选项----加载项----管理【com加载项】，转到----把"稿纸向导、书法加载项、斜线表头向导、信封向导、office special symbol input add-in"五项取消(若有六项或更多，一并取消试试，我的有六项，全取消，就ok了）----确定。

vista： word选项----加载项----管理【com加载项】，转到----把几个勾勾都取消掉----确定，即可。VISTA中注意要以管理员身份进行，因为这些写入了注册表。（具体方法是，到office的安装目录，找到word.exe文件，反键，选以管理员身份登录，再进行设置即可）

解决方法2:

1.如已安装，则可执行安装文件，选择"添加或删除功能"，把共享功能里的"VBA项目的数字证书"装上，问题即可解决。 2.如还未安装WORD，则可在安装时选择共享功能里的"VBA项目的数字证书"装上，问题即可解决。

参考链接： http://hi.baidu.com/xnail/blog/item/dc210ef3f61401cc0b46e071.html

Posted by eygle at 5:58 PM | Permalink | Comments (0) | 软件工具 (21)

November 17, 2009

如何继续使用8.5版本的MSN

新版的MSN对于我的破电脑来说实在是太重量级了，所以从网上找了一个方法，继续使用8.5的算了。

使用 ResHacker.exe 打开 msnmsgr.exe 在 Version Info > 1 > 1033 中找到 "ProductVersion"，将 "8.5.0812″ 修改为新版本的 "14.0.8064.0206" 等即可

Resource Hacker，Compile Script ，保存即可。

再用一段8.0吧。

Posted by eygle at 2:48 PM | Permalink | Comments (2) | 软件工具 (21)

November 13, 2009

数据库因ora-600[ktbair1]和ora-7445[ksmudr]宕机处理

摘录老周的一篇文章，原文地址： http://logzgh.itpub.net/post/3185/61974

环境：
OS: AIX 4.3.3
ORACLE: 8.1.7.4 OPS,非归档模式
没有任何物理备份，只有一个月前的逻辑备份

客户一个重要的系统因ora-600 [ktbair1]错误而异常宕机，dba偿试去启动时，还是报这个600号错误。

在告警日志文件中我们发现以下错误：

Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41086_ora73.trc:
ORA-00600: internal error code, arguments: [ktbair1], [1], [7], [], [], [], []
Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41086_ora73.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00600: internal error code, arguments: [ktbair1], [1], [7], [], [], [], []
Errors in file /oracle/app/oracle/admin/ora73/bdump/pmon_31066_ora73.trc:
ORA-00474: SMON process terminated with error

该600号错误的错误堆栈如下：

----- Call Stack Trace -----
calling call entry
location type point
-------------------- -------- -----------
ksedmp+00fc bl ksedst
ksfdmp+0018 bl ksedmp
kgerinv+00e8 bl _ptrgl
kgeasnmierr+004c bl kgerinv
ktbair+00d4 bl kgeasnmierr
kdourp+09a0 bl ktbair
kcoapl+0650 bl _ptrgl
kcbapl+0080 bl kcoapl
kcrfwr+0db4 bl kcbapl
kcbchg1+14fc bl kcrfwr
kcbchg+00a0 bl kcbchg1
ktuapundo+01dc bl kcbchg

从中我们可以知道，该600号错误是发生在事务回滚的阶段，在oracle回滚事务时发现块信息与redo信息不一致导致的。
于是开始我们相信增加10513事件以禁止smon进程回滚事务可以正常启动数据库。

但是增加10513事件后，启动数据库，却报出了一个ora-7445[ksmudr]错误。错误堆栈如下：

----- Call Stack Trace -----
calling call entry
location type point
-------------------- -------- ------------------
ksmudr+004c ? 00000000
ksmfrs+001c bcl ksdxexeotherwa+012
kcbema+08a0 bl ksmfrs
kcrpap+011c bl kcbema
kcratr+0498 bl kcrpap
kctrec+0588 bl kcratr
kcvcrv+1530 bl kctrec
kcfopd+02e4 bl kcvcrv
adbdrv+0640 bl kcfopd
opiexe+2380 bl adbdrv
opiosq0+0c80 bl opiexe
kpoal8+06f8 bl opiall0
opiodr+06bc bl _ptrgl
ttcpip+0a74 bl _ptrgl
opitsk+06d8 bl ttcpip
opiino+0670 bl opitsk
opiodr+06bc bl _ptrgl
opidrv+056c bl opiodr
sou2o+0028 bl opidrv
main+0128 bl sou2o
__start+0090 bl main

从metalink上搜索该7445错误，基本上都是讲内存corruption方面的问题，未有任何有用的线索。
增加10231事件，错误依旧。

于是我们打算跟踪oracle启动过程，增加10046事件，启动数据库，通过产生的trace文件发现此时oracle启动在刚开始就报错了，
也就是没还有到查询数据字典和创建bootstrap$基表的过程，
而前面的600号错误是在回滚的阶段的报错。于是怀疑oracle在读取数据文件的checkpoint时就报错了。

于是偿试将其中一个数据文件offline drop(因为是非归档模式)掉后，再做recover datafile,然后将数据文件online起来，操作成功。
偿试recover database，又报出前面的ora-7445错误。至此基本上可以肯定是某个数据文件有问题导致了ora-7445错误。
于是先将数据库暂时改成归档模式将所有的文件都offline drop，再一个一个做recover datafile，然后online启来。
在这个过程中有两个文件出错，其中一个是6号文件，其是indx表空间，这个祼设备在物理上是不存在的，并且这个表空间里面没有任何数据，
直接将该文件offline即可，不用理会。另外一个是38号文件，它是属于data表空间的(最重要的表空间)，将其offline drop掉后，
将所有的事件去掉，偿试将数据库open，open成功！但是过了几分钟后数据库又宕下来了，报出前面的600号错误，
从告警日志里面可以看出是smon进程在做事务回滚导致的。于是此时再增加10513事件后，可以正常启动数据库，并不会自动宕机下来。

至此，数据库可以正常打开，但是38号文件无法online起来，所有的业务还是无法继续。我们采用dbv检测38号文件，未有坏块。
我们偿试查看38号文件上面有多少的表格和索引，但是dba_extents视图无法查看，报出ora-8103的错误。

同时我们发现查看dba_free_space和dba_data_files几张视图时，都会报出ora-8103错误。这表明oracle的基表上面数据有问题！

偿试做recover datafile 38也是报出ora-7445错误。与此同时在alert日志里面不断地报出下面的错误：

Errors in file /oracle/app/oracle/admin/ora73/bdump/smon_41412_ora73.trc:
ORA-00376: file 38 cannot be read at this time
ORA-01110: data file 38: '/dev/rlvdata54'
ORACLE Instance ora73 (pid = 8) - Error 376 encountered while recovering transaction (43, 70) on object 34060.

通过dba_objects视图我们发现34060对象是so表(非常重要的表格).

问题处理到这里，当时觉的几乎没什么希望了，数据字典有问题，38号文件也有问题，并且是处于recover状态。除了重建数据库，
将一个月前的数据导入外好像没有什么好的办法了。

此时想起以前我用bbed修改数据文件头的scn号，以将表空间online起来的那次事件，为了使38号文件打开，我们决定再次采用
bbed修改38号文件的scn号，看看能不能将38号文件online启来。
修改成功后，直接online数据文件不行，还是要做recover，recover datafile 38很快做完，然后顺利将38号文件online启来。
此时查看38号文件上面的表格和索引，发现几乎所有的表格和索上都有一部分数据存在38号文件上面。

至此还是怀疑38号文件上面的错误信息引起了这一切，我们认为38号文件上面的数据块肯定有问题，但是采用dbv又查不到错误。
此时想起前面用bbed修改scn，校验数据文件时，它将587219块标志为failing状态(这个状态不知道是什么意思)通过Dba_extents视图，找出该块对应的segment就是so表。

我们偿试analyze table so validzte structure;执行正常，未报出任何错误。同时我们偿试select count(*) from so;返回结果也正常。

再偿试create table bak_so as select * from so;报出前面一样的ora-7445错误。
采用10231事件，想跳过坏块，取出正常的数据，但是依然报同样的ora-7445错误。然后我们采用rowid方法跳过该块，取出so表中其他正常的数据(丢失了64条记录)。将so表删掉重建，将索引建立回去，重新对so表做analyze分析。同时将外键增加回去。

至此一切正常，测试业务，正常！

后语：
真是没想到了一个普通表格上面的数据块有问题导致了这么大的问题，这个块oracle未将它标志为坏块，而是failing状态，不知道是什么意思，如果标志为坏块，那事情就不会这样了。

Posted by eygle at 4:12 PM | Permalink | Comments (0) | Oracle摘 (78)

October 1, 2009

如何在shell脚本里使用sftp批量传送文件

原文链接：http://bbs.chinaunix.net/archiver/tid-508290.html

主要步骤如下:

1.为运行shell脚本的本地用户生成密钥对
2.将其中的公钥分发到sftp欲登录的远程服务器上
3.编写并以上面的本地用户运行shell脚本

一.生成密钥对

在shell脚本中使用sftp时必须用到密钥对(公钥和私钥).可使用下列方式生成(SSH 2.X版本),这里本地用户记为:local_user:

$ ssh-keygen -dsa

屏幕提示:

Generating public/private dsa key pair.

Enter file in which to save the key (/home/local_user/.ssh/id_dsa):
# 按回车保存为: /home/local_user/.ssh/id_dsa,即当前用户local_user的私钥

Enter passphrase (empty for no passphrase):
# 按回车,表示读取密钥时不需要密钥的密码

Enter same passphrase again:
# 确认密钥的密码,必须和上面的输入相同

Your identification has been saved in /home/local_user/.ssh/id_dsa.
# 私钥保存信息

Your public key has been saved in /home/local_user/.ssh/id_dsa.pub.
# 公钥保存信息

The key fingerprint is:
ec:41:e8:08:38:0b:f8:1e:bc:92:98:32:fc:d7:69:7d ...
# 密钥指纹

二.分发公钥

为了使用密钥,必须将公钥分发到欲登录的远程服务器上,这里远程服务器记为remote_host,欲登录的远程用户记为remote_user

1.copy公钥到欲登录的远程服务器的远程用户的家目录下,例如:

copy id_dsa.pub到remote_host:/home/remote_user/.ssh/

若目录/home/remote_user/.ssh/不存在,请先创建之.

2.将copy来的公钥文件改名为authorized_keys

3.修改公钥文件的访问权限

chmod 644 authorized_keys

三.示例

目标:

从远程服务器remote_host:/home/remote_user/data/
传送下列文件到本地计算机的当前目录: /home/local_user/data/:

20050201
20050202
20050203
20050204
20050205

方式1: 批模式

sftp提供了一个选项-b,用于集中存放sftp命令(该选项主要用于非交互模式的sftp).因此对于上面的目标,可以生成如下的命令文件:

cd /home/remote_user/data/
lcd /home/local_user/data/
-get 20050201 .
-get 20050202 .
-get 20050203 .
-get 20050204 .
-get 20050205 .
quit

这里存为: sftp_cmds.txt

说明: get命令前加一个"-"以防止其执行错误时sftp执行过程被终止.

以下为脚本示例:

#!/bin/sh
sftp -b ./sftp_cmds.txt remote_user@remote_host

方式二:

#!/bin/sh
sftp remote_user@remote_host << EOF
cd /home/remote_user/data/
lcd /home/local_user/data/
-get 20050201 .
-get 20050202 .
-get 20050203 .
-get 20050204 .
-get 20050205 .
quit
EOF

Posted by eygle at 9:19 AM | Permalink | Comments (1) | 软件工具 (21)