下载和安装Mondrian
Mondrian官方网站上的文档Installation部分似乎很久没更新了,例如文档里提到下载.zip格式的打包文件,实际上网站和sourceforge上都没有提供,只提供了.jar格式(网站提供版本为3.12.0.1),看起来已经转移到github了。经过实践,安装的方法如下:
Mondrian官方网站上的文档Installation部分似乎很久没更新了,例如文档里提到下载.zip格式的打包文件,实际上网站和sourceforge上都没有提供,只提供了.jar格式(网站提供版本为3.12.0.1),看起来已经转移到github了。经过实践,安装的方法如下:
SQL Server里提供了Pivot
关键字可以帮助实现交叉表格,但DB2里似乎没有等价的东西。实现的方法稍微复杂一点,以下是一个例子。
SELECT location,
MAX(CASEWHEN metric='PH'THEN value END) as PH,
MAX(CASEWHEN metric='Hg'THEN value END) asHg,
MAX(CASEWHEN metric='Fe'THEN value END) as Fe,
MAX(CASEWHEN metric='Mn'THEN value END) as Mn
FROM data_view
GROUPBY location
其中data_view表/视图有location、metric和value这三个字段,数据是下面这个样子:
location1 PH 1.142575278063135location1 Hg 0.0018310994140037379
location1 Fe 0.2974983113601452
location1 Mn 0.09548843270448454
location2 PH 6.096025515217242location2 Hg 0.005575948698159294
location2 Fe 0.32657056877142043
location2 Mn 0.009418315198912612
得到的交叉表:
LOCATION PH Hg Fe Mn
location1 1.1425752780631350.00183109941400373790.29749831136014520.09548843270448454
location2 6.0960255152172420.0055759486981592940.326570568771420430.009418315198912612
APP Heap区不足,用DB2 UPDATE DB CFG FOR DBNAME USING APPLHEAPSZ 1024
可以解决。注意要重启DB2以便让更改生效。
在控制中心里,选择数据库备份路径时要选到xxx.0的上一层,时间戳要与备份时一致(可通过查看备份路径里的文件夹和文件名得到,如20081007165742
)。恢复数据库的命令行格式如下:
db2 restore <dbname> incremental from <imagepath> taken at <timestamp>
恢复数据库时提示错误信息,例如:
SQL2570N 由于操作系统不兼容或者指定的 RESTORE 命令不正确,所以在目标操作系统 "NT-32" 上从源操作系统 "AIX-32" 上创建的备份进行复原的尝试失败。原因码:"1"。
按照错误码(1)对应的用户响应,应该使用db2move实用程序:
要使用这个特定的备份映像,应在与创建该备份 时所在的操作系统“复原兼容”的系统上进行复原 。要将数据库从一种操作系统类型移至另一操作系 统类型,请使用 db2move 实用程序。要了解有关相互“复原兼容”的平台以 及 db2move 实用程序的详细信息,请使用诸如“跨平 台备份和复原”或“使用不同操作系统”之类的短 语来在 DB2 信息中心( http://publib.boulder.ibm.com/infocenter/db2luw/v9 )中执行搜索
Pivot Query
另一个方法(经实验不好用)
又一个方法(感觉比较复杂,没试)
搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2008/08/19/1271120.html
二十天没有写新日志,真对不起关心这个blog的朋友们。
从四月份开始准备了三个月,这些天参加了Oracle 9i的培训,并顺利通过了OCP全部四门课的考试。虽然证书还要一个多月才能拿到,但总算可以暂时把心放下了。目前的工作和Oracle没有直接关系,考这个一是为拿证书(以前从没考过认证),证明自己的学习能力;二是强迫自己对数据库产品进行比较全面的了解。
Oracle大学的高老师很有经验,十分感谢他,让我们在了解知识点的同时还掌握了不少对实际出现情况的应对方法,同时也感受到考过OCP绝不代表你可以处理全部问题了,没有一两年的实际经验,对于生产数据库还是少碰为妙,这和背背书应付考试完全两个概念。
虽说培训环境还不错,可每天来回路上挤三个多小时的车,我还是快坚持不住了。这周体检出血液中某种细胞低于正常值,医生说是累的,联想到程序员王俊,以及再早些我校青年教师的突然去世,深切体会到“身体是革命的本钱”所言极是,同志们都要注意那!
这个月开始又要和自己喜欢的Eclipse打交道了(Eclipse 3.1正式版已经发布),我一有时间还是会在这里写下所学的心得体会,常来看看哦。
搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/07/02/184956.html
以下针对Oracle9i数据库:
搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/05/06/150073.html
在一个项目中,客户要求除操作系统外全部使用免费软件,因此我使用了Mysql 4.0作为数据库服务器,其JDBC驱动为3.0.9版本,在给客户安装后调试一切正常。可是到了第二天,只要一登录就提示“No operations allowed after connection closed”异常,显示在浏览器上。在经过一番检查后我发现,在这种情况下只要重新启动Tomcat就恢复正常,然而到了第二天问题依旧。
在网上查找一下,原来Mysql在经过8小时不使用后会自动关闭已打开的连接,摘录原文如下:
I have a servlet/application that works fine for a day, and then stops working overnight
MySQL closes connections after 8 hours of inactivity. You either need to use a connection pool that handles stale connections or use the "autoReconnect" parameter (see "Developing Applications with MySQL Connector/J").
Also, you should be catching SQLExceptions in your application and dealing with them, rather than propagating them all the way until your application exits, this is just good programming practice. MySQL Connector/J will set the SQLState (see java.sql.SQLException.getSQLState() in your APIDOCS) to "08S01" when it encounters network-connectivity issues during the processing of a query. Your application code should then attempt to re-connect to MySQL at this point.
在客户那边,晚上时间是不会有人使用这个系统的,就造成了系统中原先没有考虑到的这个情况。
为此我试验了三种方法:
1、在数据库的url中加入&autoReconnect=true
;
2、在每次调用getSession()方法时判断session.isClosed()
是否为真,若为真则调用session.reconnect();
3、在经过两天,事实证明前两种方法都不起作用的情况下,我在这个页面找到了第三种方法,即不使用Hibernate内置的连接池(Hibernate强烈推荐不使用但我以前一直在用),改用C3P0连接池,这个连接池会自动处理数据库连接被关闭的情况。要使用C3P0很简单,先从Hibernate里把c3p0-0.8.3.jar复制到项目的lib目录中,再在hibernate.properties里去掉hibernate.c3p0开头的那些属性的注释(使用缺省值或自己需要的数值),这样Hibernate就会自动使用C3P0代替内置的连接池了。到目前为止前面的问题没有再出现过。
以前对Hibernate警告不要使用内置连接池作产品用途没有太放在心上,这次是一个教训,所以不论从稳定还是性能的考虑,都应该选择相对更加成熟的连接池。
Update: 除了连接池的原因,原先写的HibernateDAO类也有问题,在有些情况下一个session会被多个请求反复使用,现在已改正。另外,c3p0这个名字不是星球大战里那个机器人么?
搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2004/12/10/75145.html