MYSQL网站制作之在redhat 9 上安装oracle 9.2.0.4 时，...

使用它开发程序也是非常简单的。”oracle|办理
怎样在各类版本的linux上安装oracle的材料已良多了，也先容的很具体，按说只需依照
步骤一步步来，应当不会呈现成绩。我也已经在redhat9上安装过oracle9.2.0.1,没有呈现
任何成绩。但比来我在redhat9上安装oracle9.2.0.4(这个版本是OTN上能够下载的，9.2.0.1
的下载链接已没有了)时，在最初利用DBCA创立数据库时，呈现了以下的毛病:


clickfinish,弹出确认画面，clickok,这时候，本应当进进DBCA创立数据库的画面，DBCA却非常加入，commandline显现的笔墨为:
/u01/oracle/product/9.2.0.4/bin/dbca:line124:2542Killed
$JRE_DIR/bin/jre-DORACLE_HOME=$OH-DJDBC_PROTOCOL=thin-mx64m-classpath$CLASSPA
THoracle.sysman.assistants.dbca.Dbca$ARGUMENTS
(蓝色的部分是DBCA的举行号，分歧的呆板上不不异)
我实验了良多次，城市呈现这个毛病。可我已经在redhat9上安装过9.2.0.1,没有任何
成绩，看来应当是9.2.0.4的成绩了。我在google上搜刮到一篇在fedoracore1上
安装9.2.0.4的文章(http://www.oracle-base.com/articles/9i/Oracle9iInstallationOnFedora1.php)
,个中有如许一段:
BeforeadatabaseinstancecanbecreatedsomeoftheOracletoolsmustbeforcedtolookatanalternativeJRE:

mv$ORACLE_HOME/JRE$ORACLE_HOME/JRE_ORIGln-s/usr/java/jdk1.3.1_09/jre$ORACLE_HOME/JREsu-rootln-s/usr/java/jdk1.3.1_09/jre/bin/java/usr/java/jdk1.3.1_09/jre/bin/jreln-s/usr/java/jdk1.3.1_09/jre/bin/i386/native_threads/java/usr/java/jdk1.3.1_09/jre/bin/i386/native_threads/jreexit
WiththisdonetheDBCAcanbestartedusingdbcafromthecommandline.
个中的jdk1.3.1_09是作者请求从sun网站下载的。
云云看来应当是JRE的版本不合错误了。oracle一样平常利用的JRE是1.1.8(其实不分明为何)
到$ORACLE_BASE/jre目次下，发明oracle本人已有1.3.1版的JRE
ls$ORACLE_BASE/jre
1.1.8/1.3.1/
只需利用1.3.1的JRE就能够了。经由过程观察dbac的script,我的修正办法以下:
1.rm$ORACLE_HOME/JRE(此JRE目次是1.1.8的标记链接)
2.ln-s$ORACLE_BASE/jre/1.3.1$ORACLE_HOME/JRE
3.cd$ORACLE_BASE/jre/1.3.1/bin
4.ln-s$ORACLE_BASE/jre/1.3.1/bin/.java_wrapperjre
(大概:ln-sjavajre)
5.cdi386/native_threads
6.ln-sjavajre

这时候，从commandline启动dbca,就能够办理下面的成绩。

感受:
实在oracle本人就能够做好这些事变，为何要用户往完成这些单调的事变呢？
MySQL的支持者们却认为，MySQL所保留的功能都是精华，并且是你部署、MySQL学习教程配置和维护这个数据库所必不可少的一些功能。

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

大家注意一点。如下面的例子：

在select语句中可以使用groupby子句将行划分成较小的组，然后，使用聚组函数返回每一个组的汇总信息，另外，可以使用having子句限制返回的结果集。

呵呵，这就是偶想说的

换言之，只有在不断的失败中尝试成功，而关于失败的总结却是很少的

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。