创新谈-王忠海

写在前面的话：

我从 97 年毕业后开始做的是编程工作， 99 年开始接触 Oracle 数据库编程，慢慢的工作重心向数据库方向转移，并且随着时间的推移也越来越喜欢数据库。很多时候遇到问题的时候，容易从数据库的角度去考虑问题的解决方法。我对“创新应用”、“行业借鉴经验”、“应用难点技巧”理解可能不太深刻，因为我不能够很清晰的将这几个方面分开来，所以，可能我写的内容相互都有关系吧。

创新性应用：    

应用 1 ：将 " 特情信息 " 应用到数据库中来    

特情信息是公安行业的一个保密很强的信息，目前很多地方都只有侦察员自己掌握情况。但是随着信息量的增多，这种管理方式的弊病也日益突出，信息不能有效共享。 2005 年 12 月某市公安局与我讨论将信息存放在 Oracle 数据库中的可行性，一个根本要求是保密性要特别强。经过仔细考虑，我为该项目提供了下面的思路：

1．  采用 VPD 策略数据库，不同的 Oracle 用户严格控制可查询权限。

2．  对表中的关键字段进行加密。例如嫌疑人姓名、住址等。前台录入数据是正常录入的，只是在存入的时候对加密字段调用加密存储过程，然后将其加密后再存入数据库。前端显示的时候显示解密后的内容。

3．  加密、解密的存储过程本身用 wrap 程序加密，并且存储过程需要传递正确的解密密码。这样，即使是 Oracle DBA 用户，也无法通过后台查看关键字段的真实内容，即使知道用哪个解密函数，也不知道该使用什么解密密码。而且由于存储过程的加密，入侵者也不可能根据存储过程来逆推，从而充分的在数据库一级保障了信息的安全。

4．  如果开发网络版程序，则为了控制网络传输的安全，采用 SSL 和数字证书。

通过以上措施，并且简单的给用户做了个演示例子，用户表示满意，目前此项目正处于业务调研阶段。

 

应用 2 ：实现自己的 " 网格 "(GRID) 计算

Oracle 10g 的一个核心概念叫做 " 网格计算 " ，简单的来说也就是很多机器、资源共同服务，好像一个库一样。我在实际工作中，还没有听到网格这个概念的时候，已经在某项目中简单的实现了类似的功能。

项目简介：

公安业务数据通过计算机采集已经有多年的历史，积累了大量宝贵的数据。如何充分利用这些数据就显得更加重要。近几年，针对这些原始数据的数据挖掘需求不断增加，很多公司也把精力放在了这个上面。一个简单需求例子是：根据某个特定的案子，查找到库中相似的案子或线索。我们称之为一个 " 比对 " ，下同。因此，项目的成功与否关键在于是否对业务有深刻的了解，以及实现的模式是否符合公安网络的实际情况。通过仔细考虑，我们认为市面上的数据挖掘工具因为成本、灵活性等原因并不适合刑侦业务，因为影响判断的因素太多，必须尽量让计算机具有 " 破案专家 " 的头脑来考虑方方面面的情况。这就需要广泛建同义词库，根据各种情况为符合条件的结果加权，综合排名后将排名考前的信息提供给用户。抛开业务上的需求，考虑到每一个提交的比对（不是具体 SQL 语句），都可能需要分成上百个 SQL 查询，因此服务器性能就很重要。

我的方案是：

1． 10 台计算机上安装 ORACLE 服务器，然后开发一个用于抽取关键数据应用程序，分别安装在这 10 台计算机上，每一台机器我们称之为一个“比对器”，定期从业务数据服务器抽取数据到各自的数据库。

2． 安装一个接收查询请求的数据库，我们称之为中心查询库，并开发程序来接收前端应用程序发送的比对请求。

3． 用户在前端发出比对请求，然后进入等待状态，每隔一段时间自动询问中心查询库，查看比对是否完成。

4． 中心查询库接到比对请求后，查询比对器的状态，找到比较闲的比对器，将比对提交给该比对器。

5． 比对器完成比对后，将结果反馈给中心查询库。

6． 用户前端的程序询问中心查询库，得知结果比对完成后，下载比对结果，至此比对完全完成。

这个方案的具有如下优点：

1． 10 个比对器都可以用来查询，不会对业务数据库造成负担，而且可以根据需求随时增加或减少

2． 成本低，实现简单。

通过向公司领导汇报、与开发组论证，最终选定了这个方案，目前本项目在进一步的业务调研，开发也同时进行。

 

行业借鉴经验：

说到行业借鉴经验，其实很多都不是和数据库相关的，而是具体的业务。业务上我不能过多涉及，一是跑题，二是有一些保密的东西。从数据库上仔细想了想，感觉我能想到的更像是常识，写下来仅供参考。

1． 数据库结构设计

Ø        如果查询需要，可以考虑设计冗余字段来提高查询性能。例如对姓名的查询，有的人可能用同音查询，因此可以考虑一个表内也有拼音这个字段。或者不同表关联的时候，如果行是一对一的情况，而且经常一起查询，也可以考虑将从表的字段冗余。

Ø        关于索引，并不是说每个查询都用到的字段都要建索引。这是一些结构设计中最容易犯的错误。例如，如果系统中的查询基本上都是有 6 到 8 个条件，涉及到 5 到 6 以上张表，每个查询条件字段都有索引，有的时候是灾难性的。因为 Oracle 很可能选择错的索引而导致查询很慢。怎样来判断 Oracle 选择了正确的还是错误的索引呢？一个最简单的方法是看执行计划，通常，我们期望 Oracle 第一步骤用到的索引最大幅度的筛选掉记录。这样就会使 I/O 少，读一致性块也需要相对少，一般速度也很快。一个通用的规则是，如果一个经常用于查询的字段唯一值很少，而且经常和其它的筛选性更大的条件在一起使用，那么该字段一般不要用所引，如性别。

Ø        表名和字段名尽可能的规范，字段的长度要够用但避免过大。

Ø        结构设计好了之后，尽可能多建一些全方面的测试数据，并有针对性的进行一下数据库优化。

2． 数据库安全性的考虑

除了常规的能够想道的安全方面的问题，如用户和口令、数据库补丁、操作系统补丁之外，还可从以下几个方面来考虑：

Ø        如果系统采用三层架构方式，或者是浏览器 / 服务器方式，那么可以考虑把数据库服务器放到一个私有网络里面，这样外网就无法直接访问到数据库，也就更无法进行攻击了。进一步的考虑还可以更改默认的监听器的端口号，也就是说，正常情况下，数据库只对中间层开放，从而进一步提高安全性。

Ø        硬件安全性、系统安全的考虑：磁盘阵列柜，高级复制， DATAGUARD ， RAC 等等高可用措施，都要根据用户的具体需求加以考虑。

3． 备份数据库和定期数据库健康检查

一定要制定适合需求的备份计划，否则一旦出现问题，后果可能非常严重。数据库健康检查也属于日常工作了，包括性能方面，存储方面等等，都应该有可行的日常规范，这样通常能够在问题发生之前就把隐患解决掉了，这是作为 DBA 的一个基本职业素养。

应用难点技巧：

现在，日常中我维护的数据库一般都很稳定。我现在感觉 Oracle 的管理和维护实际上是很简单的，我想从最常见的系统出现硬故障和软故障谈谈我的看法。

1.        所谓的硬故障，就是指数据库崩溃，或者硬件出现问题，或者如果问题不能解决，应用程序就无法急需的问题。这类问题解决起来很简单，大致上可以遵循下面的方法：

Ø        硬件故障首先解决硬件故障

Ø        如果数据库崩溃尝试用 sqlplus 或者 svrmgrl 手动启动数据库，查看具体的报错信息。

Ø        其它问题查看发生问题时的 Oracle 错误号，查看 alert 日志和跟踪日志来进一步定位。

Ø        根据错误号，自己掌握的就解决，如果不懂，则可以在互联网上查找，通常可以解决。我在网上查找问题解决方法的顺序通常是：

²       GOOGLE

GOOGLE 是最好的良师益友，善于用 GOOGLE ，可以让你的水平在同事的惊讶眼光中迅速提高水平。我的绝大部分问题基本上都是在 GOOGLE 上解决的。

²       METALINK

METALINK 是 Oracle 官方技术网站，权威性不言而喻。

²       专业网站发贴求助。如 www.itpub.net 等。

有的时候有些问题不好描述，也就是说不好找到关键词来形容，可以上专业的论坛上来发贴询问，通常会获得热心的网友的帮助。

Ø        查找到解决方法后实施。但实施前如果有危险的操作一定要注意数据库的备份。

2． 对于软故障，我主要指性能方面的问题。这个可能需要更多的理论和实践知识了。可以通过系统的学习来不断提高优化数据库的能力。不过如果还没掌握优化技巧的人也不要着急，可以首先学会怎样为数据库做 statspack 报告——这个很简单，几分钟可能就能够掌握了，然后需要做的是把 statspack 报告放到一些大型论坛上去，如前文提到的 ITPUB ，自然有好多专家来帮你解答。