最终确定的设计是采用客户端，也就是说，将客户端的BI工具分发给客户的客户，每月再由客户通过邮件、光盘等方式将付费的数据采用加密的方式传递给数据使用单位。这些单位收到数据后，在客户端打开，客户端负责解密和展示。

        BI部分我轻车熟路，由于要“分发”，所以只能选择Opne Source的，我比较看好Jasper Report，可以培训他们使用Ireport做报表，然后将做好的定义文件打包一起分发；客户端程序也不复杂，只需要修改Jasper的viewer就可以了。

        除了担心Ireport太次，容易让客户使着使着抓狂（这就是后话了，实在逼得不行，只能围绕IReport再作开发了，好在都有源码）之外，近期最让我烦恼的就是如何选性数据库。要说BI平台数据库的选型，参加革命一两年的同志就可以说出一大堆各种数据库的对比，但是那些都是大型的，反而小型的这次把我难住了。

        研究了一圈以后，获得提名的数据库是他们几个：

• access：数据类型有些另类，而且密码太容易被攻破，最大的问题在于要为此付费；
• hsqldb：这是最可能成为胜利者之一的数据库，支持csv，配置分发容易，但是最终败北在性能上，当单表数据量在100万以上的时候，csv文件达到40兆，执行group by的sql语句用了300秒！这和sql执行效率无关，性能瓶颈在硬盘文件上，毕竟由于hsqldb没有在数据文件存储上花时间，只是挂个csv；
• firebird：看标题就明白，这是胜利者，下面我会说说它的好处。
• sybase asa：数据能加密，性能不错，但是败在“需要付费”上；
• derby：它和fb有一拼，不管在性能上还是在易用性上，但是最终有两点不如fb，第一、embedded版本完全没有数据认证，导致谁都可以打开数据库执行sql语句；第二、数据库是以一个目录存储的，而fb只有一个文件；
• sqllite：不支持数据加密，另外，对中文，尤其是用中文order by的时候时常错误；还有就是完全没有用户认证；不过据说执行效率不错；
• mysql：要说最像样的就是这个了，但是严格说起来，虽然mysql也可以不通过安装，直接拷贝就能使用，但是距离embedded还差一块，所以不考虑了。

        行了，言归正传，最后firebird胜出，很荣幸的成为这个项目的数据库。原因有这么几个：

1. 数据文件是单一，部署、分发相对简单；
2. 用户不需要安装，像这个项目，只是用embedded方式，只需要把icudt30.dll、icuin30.dll、icuuc30.dll、jaybird21.dll、fbembed.dll五个文件和目录intl（里面有两个文件，是处理字符集的）放在程序启动目录就行了；
3. DBC配置、引用比较简单，driver就是一个jaybird-full-2.1.6.jar，看了其他的一些资料，都搞不清他的lib目录里面的其他的jar是做什么的，仔细看说明以后终于明白，原来这个full版本就是其他几个的集成，为了调用方便，人家不但提供了集成，又给你拆开了，你爱用哪个用哪个。有点像Spring的2.5兆的jar和无数个几十k的小文件的关系。
4. 中文支持的不错，但是要在建库的时候使用GB_2312字符集；
5. 一个叫FlameRobin的工具也不错，起初有些别扭，窗口和窗口都分着，典型的Linux风格，后来习惯了；

最后附上embedded的连接例子吧：

Java代码

1. long start = Calendar.getInstance().getTimeInMillis();   
2. org.firebirdsql.pool.FBWrappingDataSource dataSource = new org.firebirdsql.pool.FBWrappingDataSource();   
3. // 设定数据库文件   
4. dataSource.setDatabase("TEST.FDB");   
5. // 可以不设   
6. dataSource.setDescription("An example database of test");   
7. // 设定EMBEDDED就行了，说明上写着另外两种type是TYPE2和type4，干什么用的没研究，谁知道回一个阿   
8. dataSource.setType("EMBEDDED");   
9.   
10. try {   
11.     dataSource.setLoginTimeout(10);   
12.       // 这个地方是最让我痛苦的，设定了密码没用！下面会说。   
13.     java.sql.Connection c = dataSource.getConnection("user_1", "");   
14.   
15.     java.sql.Statement stmt = c.createStatement();   
16.       // 100万的大数据量   
17.     java.sql.ResultSet rs = stmt.executeQuery("SELECT count(id) FROM largedata");   
18.     if(rs.next()) {   
19.         System.out.println("count: " + rs.getString(1));   
20.     }   
21.     stmt.close();   
22.     c.close ();   
23. } catch (java.sql.SQLException e) {   
24.     e.printStackTrace();   
25.     System.out.println("sql exception: " + e.getMessage());   
26. }   
27. System.out.println("==>" + (Calendar.getInstance().getTimeInMillis() - start)/1000);   
28.   
29. // 在对id作了索引的情况下，你猜多久？1秒钟！同时做一个count和sum的group by，在没有索引的情况下40秒  

long start = Calendar.getInstance().getTimeInMillis();
org.firebirdsql.pool.FBWrappingDataSource dataSource = new org.firebirdsql.pool.FBWrappingDataSource();
// 设定数据库文件
dataSource.setDatabase("TEST.FDB");
// 可以不设
dataSource.setDescription("An example database of test");
// 设定EMBEDDED就行了，说明上写着另外两种type是TYPE2和type4，干什么用的没研究，谁知道回一个阿
dataSource.setType("EMBEDDED");
try {
dataSource.setLoginTimeout(10);
// 这个地方是最让我痛苦的，设定了密码没用！下面会说。
java.sql.Connection c = dataSource.getConnection("user_1", "");
java.sql.Statement stmt = c.createStatement();
      // 100万的大数据量
java.sql.ResultSet rs = stmt.executeQuery("SELECT count(id) FROM largedata");
if(rs.next()) {
System.out.println("count: " + rs.getString(1));
}
stmt.close();
c.close ();
} catch (java.sql.SQLException e) {
e.printStackTrace();
System.out.println("sql exception: " + e.getMessage());
}
System.out.println("==>" + (Calendar.getInstance().getTimeInMillis() - start)/1000);
// 在对id作了索引的情况下，你猜多久？1秒钟！同时做一个count和sum的group by，在没有索引的情况下40秒

        补充一把：嵌入式数据库的让我最痛苦的是没有办法做安全设定，一位仁兄说得好：数据文件都给人家了，做什么也没用。

        我觉得太有道理了，就拿Derby来说，完全没有安全性设定，谁都可以打开，FB呢，稍微好一点儿，不知道用户名就打不开（这是授权的事，说白了还是没认证），上面的例子，明明数据库的用户是user_1，密码123，但是不论你用什么密码，都能访问数据，但是如果你不知道用户名，就没戏了。

        算是瘸子里拔将军吧。

        后来，我还煞有介事的google了一把“firebird破解”，你猜怎么着，有高人出的高招：不知道用户名也能照样打开。怎么弄我不说了，万一让“客户的客户们”谁看到了，又要逼着换方案，这谁受得了。

        不过说真的，要是谁知道embedded FB怎么保证安全，赶紧给我支两招，我都快疯了。

转自：http://s0o0e.javaeye.com/blog/251636

字体大小：大 | 中 | 小 2007-11-14 14:37 - 阅读：551 - 评论：0

1.安装和升级数据库服务器,以及应用程序工具构建和配置网络环境.

2.熟悉数据库系统的存储结构预测未来的存储需求,制订数据库的存储方案.

3.根据开发人员设计的应用系统需求创建数据库存储结构.

4.根据开发人员设计的应用系统需求创建数据库对象

5.根据开发人员的反馈信息,在必要的时候修改数据库的结构

6.管理数据库的用户维护数据库的安全性

7.控制和监控用户对数据库的存取访问

8.监控和优化数据库的性能

9.制定数据库备份计划,灾难出现时对数据库信息进行恢复

10.备份和恢复数据库

11.联系数据库系统生产厂商,跟踪技术信息

12.解决客户端中间层和服务器的链接问题

13.保证安全连接

每日工作:

1 确保服务器工作状态正常,各类数据库状态正常

2 检查硬盘空间是否够用

3 查看数据库日志,查看跟踪文件,检查是否有错误信息

4 检查备份的有效性

5 通过系统的性能监视器对服务器的性能参数监控发现数据库的性能是否下降,寻找原因并解决

6 填写dba日志

每周工作:

1 监控数据库对象的空间扩展情况

2 决定是否调整存储参数

3 对系统健康检查

4 检查删除没有任何意义的数据对象

5 检查删除没有意义的约束和触发器

6 对每周的备份检查处理

每月工作:

1 根据上面的检查情况,分析数据库中是否有影响性能的存储碎片存在

2 根据数据库性能的历史数据,决定如何优化性能

3 处理每日每周每月的备份

4 总结工作,提出下一步的管理计划

Oracle DBA日常工作总结

Oracle管理员应按如下方式对Oracle数据库系统做定期监控：

1、每天对Oracle数据库的运行状态、日志文件、备份情况、数据库空间使用情况、系统资源使用情况进行检查，发现并解决问题。

2、每周对数据库对象的空间扩展情况、数据的增长情况进行监控、对数据库做健康检查、对数据库对象的状态做检查。

3、每月对表和索引等进行analyze、检查表空间碎片、寻找数据库性能调整的机会、进行数据库性能调整、提出下一步空间管理计划。对Oracle数据库状态进行一次全面检查。

每天工作

1、确认所有的instance状态正常登录到所有数据库或实例，检测Oracle后台进程：#ps -ef | grep ora

2、检查文件系统的使用（剩余空间）。如果文件系统的剩余空间小于20%，需删除不用的文件以释放空间。#df -k

3、检查日志文件和trace文件记录alert和trace文件中的错误。 cd $Oracle_BASE/oradata/<sid>/bdumptail -f alert_<sid>.log

发现任何新的ORA_错误，记录并解决

4、检查数据库当日备份的有效性

对RMAN备份方式，检查第三方备份工具的备份日志以确定备份是否成功

对EXPORT备份方式，检查exp日志文件以确定备份是否成功

对其它备份方式，检查相应的日志文件

5、检查数据文件的状态记录状态不是“online"的数据文件，并做恢复。

select file_name from dba_data_files where status="OFFLINE"

6、检查表空间的使用情况
select a.tablespace_name,round((total-free)/total,3)*100 pecentfrom (select tablespace_name,sum(bytes) free from dba_free_space group by tablespace_name) a,(select tablespace_name,sum(bytes) total from dba_data_files group by tablespace_name) bwhere a.tablespace_name=b.tablespace_name

7、检查剩余表空间
select tablespace_name,sum(blocks) as free_blk,trunc(sum(bytes)/(1024*1024)) as free_m,max(bytes)/(1024) as big_chunk_k,count(*) as num_chunksfrom dba_free_space group by tablespace_name;

8、监控数据库性能

运行utlbstat.sql/utlestat.sql生成系统报告，或者使用statspace收集统计数据

9、检查数据库性能，记录数据库的CPU使用、IO、Buffer命中率等等，使用vmstat,iostat,glance,top

10、日常出现问题的处理

每周的工作

1、控制数据库对象的空间扩展情况，根据本周每天的检查情况找到空间扩展很快的数据库对象，并采取相应的措施。

删除历史数据、扩展表空间
alter tablespace <name> add datafile '<file>' size <size>

调整数据对象的存储参数　next extent pct_increase

2、监控数据量的增长情况

根据本周每天的检查情况找到记录数据数量增长很快的数据库对象，并采取相应的措施

删除历史数据、扩表空间

alter tablespace <name> add datafile '<file>' size <size>

3、系统健康检查

检查以下内容：
init<sid>.oracontrolfileredo log filearchiveingsort area sizetablespace(system,temporary,tablespace fragment)datafiles(autoextend,location)object(number of extent,next extent,index)rollback segmentlogging & tracing(alert.log,max_dump_file_size,sqlnet)

4、检查无效的数据库对象

select owner,object_name,object_type from dba_objects where status='INVALID'

5、检查不起作用的约束

select owner,constraint_name,table_name,constraint_type,status from dba_constraintswhere status='DISABLED' and constraint_type='p'

6、检查无效的trigger
select owner,trigger_name,table_name,status from dba_triggerswhere status='DISABLED'

每月的工作

1、Analyze tables/indexes/cluster

analyze table <name> estimate statistics sample 50 percent;

2、检查表空间碎片

根据本月每周的检查分析数据库碎片，找到相应的解决方法

3、寻找数据库性能调整机会

比较每天对数据库性能的监控报告，确定是否有必要对数据库性能进行调整

4、数据库性能调整，如有必要进行性能调整

5、提出下一步空间管理计划，根据每周的监控，提出空间管理的改进方法