【TechTarget中国原创】1、SQL Model子句

　　也许现在最受关注的就是Oracle数据库10g新数据仓储特征中的SQL Model子句。该子句让用户将类似数据表模型插入select语句中，以前这在某种程度上属于的OLAP服务器关注的范围，如Oracle Express以及Oracle 9i OLAP。SQL Model子句给Oracle分析性的查询一个全新的标准并且说明了SQL一般工作模式的一些缺陷。

　　SQL Model子句是为了说明以下的情况：在过去，客户先从关系型数据库中取出数据、然后将它们导入数据表如Microsoft Excel中。通常，这些模式涉及一系列宏，这些宏里的数据集合包括一系列的商业尺度、时间变更周期以及一套复杂的、很难用平常的SQL表示的商务尺度。我设法说服一些客户SQL的局限就是利用一系列独立的Excel表格，而这些给客户提供了他们所需要的分析能力、复制数据的可测量性和可靠性、然而不久缺乏对全局的控制能力也显露出来。

　　SQL Model子句让一般的SQL语句能够在select语句的结果中创建多维数组，在这一数组上执行一些行间和列间的计算，然后对包含模式结果的数据表格进行升级。使用MODEL子句的SQL示例如下：

　　2. SQL Access Adviser

　　Oracle数据库10g Server Manageability的部分特征就是，SQLAccess Adviser给指定的工作量介绍了最佳索引和物化视图的结合。可行方案就是（通过DBMS_ADVISOR包）或者通过新推出的基于Web的Oracle Enterprise Manager中的 Advisor Central元件，SQLAccess Adviser最初就和Oracle9i一起建立在索引和概要advisor并且为调优和总结存储数据提供了一站式的服务。

　　更多有关SQLAccess Adviser的信息可以在OracleWorld这一白皮书上找到。

　　3、多维OLAP引擎的完善

　　利用Oracle9i，起初单独的Express多维engine现在就合和Oracle数据库连成一体了。通过Oracle10g，传统的关系型Oracle engine就开始明显起来。

　　首先就是对较大的分析型workspaces进行划分、目前在Oracle OLAP世界引进了一些高级分区选项，它们备受Oracle数据库用户的欢迎。现在分析型workspaces储存在Oracle schema的AW$表中，这一分析型workspaces能够用AW$表再进行细分并允许你将单独的analytic workspace列入10GB字段，每个表的行中都包含着一个部分。这些表还可以像其他Oracle表一样进行细分，你也可以将行放入每个表空间。再者，每个表空间当然储存在不同的物理磁盘单元的数据文档里。虽然这样做有很有益，细分分段大小也就是细分数据的唯一方法，你也不能在analytic workspace对每个分区进行详细说明。Oracle 10g OLAP现在还详细说明在analytic workspace里的哪一个对象划分进哪一个区域，如果对象相当大还能通过分段大小再进行细分。

　　分析空间的变化现在能够被区分开来，通过一些尺度或CONCAT尺度参考。10g的多维engine将每个变量部分当作单独的物理对象储存，这样就可以直接在AW$表里区分行（允许你越过不同的表空间和物理磁盘驱动器）；而变量则对于应用软件、简化数据模型以及允许Oracle执行所有高难度的任务来说仅仅只是一个对象。

　　另外一个杰出的新特征并在含Express的参量真正有所提高的是对多用户读写访问个人分析工作空间的支持。过去，Express的缺点之一就是只有一个用户可以在读写模式里访问Express数据库，这样就导致了Express开发人员开发了一整套可以选择的解决方案允许写入Express数据库。在Oracle 10g OLAP中，分析性工作空间可以附加在MULTI模式里。然后应用程序ACQUIRE单个变量附在用于读写的分析工作区间中。一旦获得一个对象（被Oracle多维engine锁定），就可以进行更新了，并且应用程序随时都可以进行修改。之后update命令的执行结果跟变量相反，该命令后跟有COMMIT。RELEASE命令的执行结果也和变量相反，这样做就是为了使其它的应用程序能够被写入。

　　观察多维引擎如何处理multi-write access很有趣。过去当用户读写口连接数据库时，带Express的数据库空间就能增大。其他的数据库在read mode中访问它，这是因为Express要为每个用户复制数据库以便让他们对待数据的意见一致。如果单个变量从10g的analytic workspace复制到临时的workspace中，这样的更新我一点都不觉得奇怪。随着更新过程往后推移（旧版本的Express Excel Add-In），最后发生变化时——主要问题就是如何数据库大小，因为旧版的Express的处理方法比理想状态下的要少。

　　Oracle10g OLAP改善了集合体，并且还允许现在一些规则成为AGGREGATE命令的数据源，这样就排除了计算和存储数据的必要，尤其是动态集合又是另外一个领域，在这里Oracle9i和现在的10g OLAP都得到了显著的改善，超过了Express。如果现存的Express系统还存在着这个问题，那么它还是值得我们更加仔细观察的。

　　更多有关Oracle10g OLAP型特征的详细信息在《OLAP 应用开发指南》中能够找到，《OLAP DML指南》以及Bud Endress写的白皮书OLAP Option to the Oracle10g Database也能找到相关信息.。

　　4、Tune MView Advisor和Query Rewrite的完善

　　Query Rewrite( Oracle从具体层级到总表的直接的查询能力)是Oracle8i和9i数据仓储的最佳特征之一，但是这些特点不稳定，你通常会发现这些查询不能被重写。有时是因为你打破了Query Rewrite的某一项限制，有时是因为你的实体化视图没有包含正确的column和集合。Oracle10g对Query Rewrite作了一系列的改善并且实体化视图调优过程应该让这一改善过程的收获更加丰富。有了Oracle数据库10g，当你的select 语句含有分析功能时，query rewrite现在就可以实现了，快速联结和设置操作系统，如union、MINUS和INTERSECT。此外，你现在能用到一个hint：/*+ REWRITE_OR_ERROR */，它在query rewrite不发生的情况下将会终止SQL语句。

　　第四行的错误:ORA-30393：该语句中的查询块不能重写

　　Oracle9i自带两个包：DBMS_MVIEW.EXPLAIN_MVIEW和DBMS_MVIEW.EXPLAIN_REWRITE，这两个包可用来诊断为什么实体化视图不能用于query rewrite。然而，尽管这些包已经告诉了你为什么不会产生rewrite，它们仍然需要你解决如何更改你的create MATERIALIZED VIEW语句确保正确产生rewrite。Oracle数据库10g还带有一个新的advisor包：DBMS_ADVISOR.TUNE_MVIEW，这个包输入了一个create MATERIALIZED VIEW DML语句后，结果就得出了一个支持query rewrite和快速更新的特征。

　　更多有关Query Rewrite和Tune MView Adviser功能改善的信息和能在TUNE_MVIEW在线文件上找到，即《Query Rewrite在线文件》和《Oracle数据库10g Oracle-by-Example指南》。

　　5、数据泵：导入和导出的代替者

　　数据泵代替了旧版IMP和EXP应用程序，它用于创建Oracle表、schemas以及数据库的逻辑备份。数据泵属于服务器应用程序（与IMP以及EXP相反，二者都属于客户应用程序），在Beta测试数据导出时的速度是旧版EXP的两倍，数据导入时是旧版IMP的10倍。数据泵是可以随时获取，通过DBMS_DATAPUMP或通过IMP和EXP（又叫IMPDB和EXPDB）还可以通过Oracle Enterprise Manager 10g.的一部分wizard delivered来获取。

　　数据泵（和新版的IMPDB以及EXPDB应用程序）在过去的IMPORT和EXPORT上进行了很大的改善，包括可恢复/可重新开始的任务、automatic two-level parallelism、使用DBLINK/listener服务名称代替pipes的网络模式（所以能选择独立的表、视图、包、索引等等进行导入或者导出而不仅仅是表或者含有IMPORT 和EXPORT 的schema），API允许第三方ETL包带有数据泵功能。