使用查询改写提高查询性能

无需变换sql查问就不妨大幅普及查问本能。 你能否为等候你的查问归来截止而感触劳累？你能否仍旧为巩固索引和调优sql而感触劳累，但仍旧不许普及查问本能？那么，你能否仍旧商量创造去世视图？有了去世视图，那些往日须要数钟点运转的汇报不妨在几秒钟内实行。去世视图不妨囊括联接（join）和汇合（aggregate），它供给了一种积聚估计算截止的本领。 在实行一个查问时，优化器会判决考察去世视图或数据驻留的普通表能否更快少许。即使优化器判决查问去世视图是更好的处置计划，那么优化器会在一个被称为“查问改写”（query rewrite）的进程中改写sql查问。在这个进程中，不须要对任何sql或运用步调代码举行窜改，以是任何运用sql考察数据库的运用步调或一定查问东西都可成绩于运用去世视图。当为计划截止而须要考察的数据数目宏大于截止（如汇合）的巨细时，最符合运用查问改写，然而它也可被用来加快高贵的联接或筹备。 正文开始引见了优化器不妨实行的查问改写典型。而后，它计划了扶助决定创造最好去世视图集的东西，使优化器不妨改写多个查问。运用那些东西创造的去世视图在其普通数据爆发变革时还不妨赶快革新。即使你不领会创造一个去世视图、一个索引或同声创造两者哪种更好，那么在oracle数据库10g中引入的sql access advisor不妨经过领会给定的处事负载扶助你做出确定。 查问改写典型 大概有很多典型的查问改写；当去世视图的设置查问与查问的文本实足配合时，就爆发最大略和最明显典型的查问改写。然而，当沟通去世视图可用来相映多个查问时，就不妨实行查问改写的最大长处。此刻，咱们将举例证明少许oracle优化器运用的准则，以决定它能否将运用去世视图来相应。 对于正文中的示例，不妨商量将一个星形形式中的purchases表看作究竟表（fact table），其范畴由time_key分别。维度表（dimension table）--time、product和customers--包括主键 time_key、product_id和cust_id。在purchases表中有援用各个维度表的外键牵制。 商量一下清单 第11中学所创造的去世视图，该视图按月按product_id计划出卖总数和出卖总度数。提防：对于用来查问改写的去世视图，必需有enable query rewrite子句。再有，初始化参数query_rewrite_enabled必需被树立为true。 代码清单 1：创造月出卖去世视图  create materialized view monthly_sales_mv enable query rewrite as select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales,    count (ps.purchase_price) as total_sales from time t, product p, purchases ps  where t.time_key = ps.time_key and    ps.product_id = p.product_id group by t.month, p.product_id; 集核计算 在正文的示例中，咱们将证明去世视图的查问并表露由explain plan获得的实行安置。清单 第22中学的查问诉求按月和按产物的平衡购买价钱。优化器不妨运用去世视图monthly_sales_mv，运用sum和count集核计算平衡购买价钱。这个示例说领会一种叫作“集核计算”的本领。 代码清单 2：赢得平衡(avg)购买价钱  select t.month, p.product_id, avg(ps.purchase_price) as avg_sales from time t, product p, purchases ps where t.time_key = ps.time_key and    ps.product_id = p.product_id group by t.month, p.product_id;    id    operation                      name               ________________________________________________  select statement   mat_view rewrite access full           monthly_sales_mv joinback  joinback本领特殊有效，由于它承诺当去世视图中没有列时举行查问改写。清单 3中的查问诉求按月和按产物类型的出卖总数，而该去世视图中并没有product.category列。但是，产物表的主键product_id列则坐落去世视图中。所以，优化器不妨将去世视图与产物表联接起来以获得产物类型。 代码清单 3：经过joinback赢得出卖总数  select t.month, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id group by t.month, p.category;    id    operation                      name               __________________________________________________     0    select statement                                      1     sort group by                                        2      hash join                                           3       table access full            product              4       mat_view rewrite access full  monthly_sales_mv 运用维度举行查问改写 在一个运用维度建立模型本领安排的典范数据堆栈中，数据中生存着驰名的“档次联系”。比方，在功夫档次中，“天”积聚成“月”，“月”又积聚成“年”。在oracle数据库中，不妨运用create dimension语句创造一个叫作“diemnsion”的东西，向优化器证明这种联系。维度东西是一个刻画性东西，除去其元数据外，它不占用空间。运用dimension东西证明的联系传闻是确凿的。oracle不会考证这一联系对于你的数据能否确定创造，它不过假如数据库处置员仍旧判决那些联系是精确的。确凿消息的其余示例是运用novalidate rely标志的牵制及备案为去世视图的先存表。 对于沿用确凿消息（囊括维度）的查问改写，初始化参数query_ rewrite_integrity必需被树立为trusted，如次所示：  alter session set query_rewrite_integrity = trusted; 比方，假如有一个功夫维度，其证明如次： [page_break]create dimension time_dim level time_key is time.time_key level month is time.month level quarter is time.quarter level year is time.year hierarchy calendar_rollup (           time_key child of           month    child of           quarter child of            year ) attribute time_key determines (day_of_week, holiday) attribute month    determines (month_name); 此刻，即使具备清单 4中诉求按年的出卖额的查问，你仍旧不妨运用monthly_sales_mv去世视图，由于维度东西中的hierarchy子句报告oracle数据库月出卖额不妨积聚成年出卖额。它运用前方刻画的joinback本领由去世视图中的“月”列获得“年”列的值。 代码清单 4：经过joinback和hierarchy赢得出卖总数  select t.year, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id group by t.year, p.category;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2      hash join                                           3       hash join                                          4        view                                              5         sort unique                                      6          table access full          time                7        mat_view rewrite access full  monthly_sales_mv    8       table access full             product 维度的attribute子句指领会一对一联系。比方，你不妨判决从time_key发端是一周中的哪一天。假如你蓄意获得年年1月份的出卖总数：你仍旧不妨运用清单 第5中学所示的monthly_sales_mv去世视图。提防该查问的where子句怎样具备一个在去世视图中没有展示的采用前提。 代码清单 5：经过joinback和attribute赢得出卖总数  select t.year, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.month_name = ’january’ group by t.year, p.category;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2      hash join                                           3       hash join                                          4        view                                              5         sort unique                                      6         table access full          time                 7       mat_view rewrite access full  monthly_sales_mv     8      table access full             product 即使优化器并未准期改写一个查问，不妨运用dbms_mview .explain_rewrite 进程来确诊该题目。这一个性出此刻oracle9i数据库及此后的本子中。 过滤后的数据 到暂时为止，咱们所给出的一切示例都运用了与购买表中的一切数据对应的去世视图。oracle9i数据库完备在去世视图仅有一个数据子集情景下改写查问的本领。比方，即使你只对1997年到2002年的出卖额感爱好，你不妨将去世视图窜改如次：  create materialized view five_yr_monthly_sales_mv enable query rewrite as select t.month, p.product_id,        sum(ps.purchase_price) as sum_of_sales,        count (ps.purchase_price) as total_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 1997 and 2002 group by t.month, p.product_id; 此去世视图可用来相应诉求从1997年至2002年数据的查问，比方，清单 6中的查问诉求2000年的出卖额。  代码清单 6：只查问去世视图  select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year = 2000 group by t.month, p.product_id;   id    operation                       name               __________________________________________________  select statement                                     1     hash join                                                  2     view                                                      3       sort unique                                               4        table access full           time                          5      mat_view rewrite access full   five_yr_monthly_sales_mv     在oracle9i数据库中，即使去世视图中没有查问所须要的十足数据，查问就不会运用去世视图。在oracle数据库10g中，仍旧减少了这一控制，所以查问改写不妨由去世视图中赢得尽大概多的数据，并运用确定表赢得去世视图中没有的数据。和平常一律，优化器在做出实行此操纵的确定时商量了有改写和无改写情景下的查问本钱。 比方，清单 7中的查问诉求2000年至2003年之间的月出卖额，它将运用从2000年至2002年的去世视图，而只须要2003年的确定表。 代码清单 7：查问去世视图和确定表  select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 2000 and 2003 group by t.month, p.product_id;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2     view                                                          3      union-all                                                    4       hash join                                                   5        view                                                       6         sort unique                                               7          table access full          time                          8        mat_view rewrite access full  five_yr_monthly_sales_mv      9       sort group by                                              10        nested loops                                              11         hash join                                                12          table access full          time                         13          partition range all                                     14           table access full         purchases                    15         index range scan            product_pk_index 运用作废的去世视图举行查问改写 你大概想领会即使确定表中的数据爆发了变革会爆发什么情景。查问改写仍将运用去世视图吗？谜底确定于初始化参数query_rewrite_ integrity的树立。query_rewrite_integrity参数有三个取值：  stale_tolerated表白纵然确定表中的数据仍旧爆发了变革，也仍旧运用去世视图。  trusted 表白去世视图未作废时才运用该视图。然而，查问改写不妨运用断定联系，如那些由维度东西或尚未奏效的牵制所证明的联系。  enforced（缺省）表白当去世视图保护能给出与运用确定表沟通的截止时才运用它。运用这一参数表示着查问改写将不运用作废的去世视图或断定联系。  精确的树立确定于运用步调的数据需要。运用作废去世视图的查问改写大概会爆发与没有运用查问改写时各别的截止。但是，即使运用确定数据，大概会由于相应查问须要处置的洪量数据而使本能逆转。在一个数据堆栈中，常常运用trusted完备级别，由于如许才不妨保护你只运用那些具备最新数据的去世视图；但是，被证明为精确（确凿任）的联系也可用来查问改写。在大普遍数据堆栈中，那些联系仍旧在索取、变换和加载（etl）进程获得了考证，所以不复须要举行考证。 分区变革盯梢 在oracle9i数据库中，oracle引入了分区变革盯梢（pct，partition change tracking）。运用这一个性，oracle9i数据库不妨盯梢去世视图的哪一局部对应于分区确定表的已革新局部。所以，即使查问不须要已革新表的局部，那么该去世视图仍旧不妨运用。 为了在去世视图中盯梢一个确定表的变革，必需对该表举行分区，而且该去世视图（在select列表中）必需囊括确定表的分区键或一个特出因变量：dbms_mview.pmarker。此因变量为确定表中的每个分区天生一个独一的操作符。 比方，由time_key对购买表举行分区。清单 第88中学创造的去世视图与前方运用的monthly_sales_mv 去世视图简直实足沟通，不过该去世视图在购买表上包括了一个附加的dbms_mview.pmarker因变量。经过包括这一因变量，当革新购买表时该去世视图承诺pct。提防：该去世视图自己并不须要被分区。 代码清单 8：具备dbms_mview.pmarker因变量的去世视图 [page_break]  使用查询改写提高查询性能  ［ 作家：chensheng913    转贴自：csdn    点击数：1    革新功夫：2005-11-9  ］ 减小字体 增大字体 无需变换sql查问就不妨大幅普及查问本能。 你能否为等候你的查问归来截止而感触劳累？你能否仍旧为巩固索引和调优sql而感触劳累，但仍旧不许普及查问本能？那么，你能否仍旧商量创造去世视图？有了去世视图，那些往日须要数钟点运转的汇报不妨在几秒钟内实行。去世视图不妨囊括联接（join）和汇合（aggregate），它供给了一种积聚估计算截止的本领。 在实行一个查问时，优化器会判决考察去世视图或数据驻留的普通表能否更快少许。即使优化器判决查问去世视图是更好的处置计划，那么优化器会在一个被称为“查问改写”（query rewrite）的进程中改写sql查问。在这个进程中，不须要对任何sql或运用步调代码举行窜改，以是任何运用sql考察数据库的运用步调或一定查问东西都可成绩于运用去世视图。当为计划截止而须要考察的数据数目宏大于截止（如汇合）的巨细时，最符合运用查问改写，然而它也可被用来加快高贵的联接或筹备。 正文开始引见了优化器不妨实行的查问改写典型。而后，它计划了扶助决定创造最好去世视图集的东西，使优化器不妨改写多个查问。运用那些东西创造的去世视图在其普通数据爆发变革时还不妨赶快革新。即使你不领会创造一个去世视图、一个索引或同声创造两者哪种更好，那么在oracle数据库10g中引入的sql access advisor不妨经过领会给定的处事负载扶助你做出确定。 查问改写典型 大概有很多典型的查问改写；当去世视图的设置查问与查问的文本实足配合时，就爆发最大略和最明显典型的查问改写。然而，当沟通去世视图可用来相映多个查问时，就不妨实行查问改写的最大长处。此刻，咱们将举例证明少许oracle优化器运用的准则，以决定它能否将运用去世视图来相应。 对于正文中的示例，不妨商量将一个星形形式中的purchases表看作究竟表（fact table），其范畴由time_key分别。维度表（dimension table）--time、product和customers--包括主键 time_key、product_id和cust_id。在purchases表中有援用各个维度表的外键牵制。 商量一下清单 第11中学所创造的去世视图，该视图按月按product_id计划出卖总数和出卖总度数。提防：对于用来查问改写的去世视图，必需有enable query rewrite子句。再有，初始化参数query_rewrite_enabled必需被树立为true。 代码清单 1：创造月出卖去世视图  create materialized view monthly_sales_mv enable query rewrite as select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales,    count (ps.purchase_price) as total_sales from time t, product p, purchases ps  where t.time_key = ps.time_key and    ps.product_id = p.product_id group by t.month, p.product_id; 集核计算 在正文的示例中，咱们将证明去世视图的查问并表露由explain plan获得的实行安置。清单 第22中学的查问诉求按月和按产物的平衡购买价钱。优化器不妨运用去世视图monthly_sales_mv，运用sum和count集核计算平衡购买价钱。这个示例说领会一种叫作“集核计算”的本领。 代码清单 2：赢得平衡(avg)购买价钱  select t.month, p.product_id, avg(ps.purchase_price) as avg_sales from time t, product p, purchases ps where t.time_key = ps.time_key and    ps.product_id = p.product_id group by t.month, p.product_id;    id    operation                      name               ________________________________________________  select statement   mat_view rewrite access full           monthly_sales_mv joinback  joinback本领特殊有效，由于它承诺当去世视图中没有列时举行查问改写。清单 3中的查问诉求按月和按产物类型的出卖总数，而该去世视图中并没有product.category列。但是，产物表的主键product_id列则坐落去世视图中。所以，优化器不妨将去世视图与产物表联接起来以获得产物类型。 代码清单 3：经过joinback赢得出卖总数  select t.month, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id group by t.month, p.category;    id    operation                      name               __________________________________________________     0    select statement                                      1     sort group by                                        2      hash join                                           3       table access full            product              4       mat_view rewrite access full  monthly_sales_mv 运用维度举行查问改写 在一个运用维度建立模型本领安排的典范数据堆栈中，数据中生存着驰名的“档次联系”。比方，在功夫档次中，“天”积聚成“月”，“月”又积聚成“年”。在oracle数据库中，不妨运用create dimension语句创造一个叫作“diemnsion”的东西，向优化器证明这种联系。维度东西是一个刻画性东西，除去其元数据外，它不占用空间。运用dimension东西证明的联系传闻是确凿的。oracle不会考证这一联系对于你的数据能否确定创造，它不过假如数据库处置员仍旧判决那些联系是精确的。确凿消息的其余示例是运用novalidate rely标志的牵制及备案为去世视图的先存表。 对于沿用确凿消息（囊括维度）的查问改写，初始化参数query_ rewrite_integrity必需被树立为trusted，如次所示：  alter session set query_rewrite_integrity = trusted; 比方，假如有一个功夫维度，其证明如次：  create dimension time_dim level time_key is time.time_key level month is time.month level quarter is time.quarter level year is time.year hierarchy calendar_rollup (           time_key child of           month    child of           quarter child of            year ) attribute time_key determines (day_of_week, holiday) attribute month    determines (month_name); 此刻，即使具备清单 4中诉求按年的出卖额的查问，你仍旧不妨运用monthly_sales_mv去世视图，由于维度东西中的hierarchy子句报告oracle数据库月出卖额不妨积聚成年出卖额。它运用前方刻画的joinback本领由去世视图中的“月”列获得“年”列的值。 代码清单 4：经过joinback和hierarchy赢得出卖总数  select t.year, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id group by t.year, p.category;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2      hash join                                           3       hash join                                          4        view                                              5         sort unique                                      6          table access full          time                7        mat_view rewrite access full  monthly_sales_mv    8       table access full             product 维度的attribute子句指领会一对一联系。比方，你不妨判决从time_key发端是一周中的哪一天。假如你蓄意获得年年1月份的出卖总数：你仍旧不妨运用清单 第5中学所示的monthly_sales_mv去世视图。提防该查问的where子句怎样具备一个在去世视图中没有展示的采用前提。 代码清单 5：经过joinback和attribute赢得出卖总数  select t.year, p.category, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.month_name = ’january’ group by t.year, p.category;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2      hash join                                           3       hash join                                          4        view                                              5         sort unique                                      6         table access full          time                 7       mat_view rewrite access full  monthly_sales_mv     8      table access full             product 即使优化器并未准期改写一个查问，不妨运用dbms_mview .explain_rewrite 进程来确诊该题目。这一个性出此刻oracle9i数据库及此后的本子中。 过滤后的数据 到暂时为止，咱们所给出的一切示例都运用了与购买表中的一切数据对应的去世视图。oracle9i数据库完备在去世视图仅有一个数据子集情景下改写查问的本领。比方，即使你只对1997年到2002年的出卖额感爱好，你不妨将去世视图窜改如次：  create materialized view five_yr_monthly_sales_mv enable query rewrite as select t.month, p.product_id,        sum(ps.purchase_price) as sum_of_sales,        count (ps.purchase_price) as total_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 1997 and 2002 group by t.month, p.product_id; 此去世视图可用来相应诉求从1997年至2002年数据的查问，比方，清单 6中的查问诉求2000年的出卖额。  代码清单 6：只查问去世视图  select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year = 2000 group by t.month, p.product_id;   id    operation                       name               __________________________________________________  select statement                                     1     hash join                                                  2     view                                                      3       sort unique                                               4        table access full           time                          5      mat_view rewrite access full   five_yr_monthly_sales_mv     在oracle9i数据库中，即使去世视图中没有查问所须要的十足数据，查问就不会运用去世视图。在oracle数据库10g中，仍旧减少了这一控制，所以查问改写不妨由去世视图中赢得尽大概多的数据，并运用确定表赢得去世视图中没有的数据。和平常一律，优化器在做出实行此操纵的确定时商量了有改写和无改写情景下的查问本钱。 比方，清单 7中的查问诉求2000年至2003年之间的月出卖额，它将运用从2000年至2002年的去世视图，而只须要2003年的确定表。 代码清单 7：查问去世视图和确定表  select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 2000 and 2003 group by t.month, p.product_id;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2     view                                                          3      union-all                                                    4       hash join                                                   5        view                                                       6         sort unique                                               7          table access full          time                          8        mat_view rewrite access full  five_yr_monthly_sales_mv      9       sort group by                                              10        nested loops                                              11         hash join                                                12          table access full          time                         13          partition range all                                     14           table access full         purchases                    15         index range scan            product_pk_index 运用作废的去世视图举行查问改写 你大概想领会即使确定表中的数据爆发了变革会爆发什么情景。查问改写仍将运用去世视图吗？谜底确定于初始化参数query_rewrite_ integrity的树立。query_rewrite_integrity参数有三个取值：  stale_tolerated表白纵然确定表中的数据仍旧爆发了变革，也仍旧运用去世视图。  trusted 表白去世视图未作废时才运用该视图。然而，查问改写不妨运用断定联系，如那些由维度东西或尚未奏效的牵制所证明的联系。  enforced（缺省）表白当去世视图保护能给出与运用确定表沟通的截止时才运用它。运用这一参数表示着查问改写将不运用作废的去世视图或断定联系。  精确的树立确定于运用步调的数据需要。运用作废去世视图的查问改写大概会爆发与没有运用查问改写时各别的截止。但是，即使运用确定数据，大概会由于相应查问须要处置的洪量数据而使本能逆转。在一个数据堆栈中，常常运用trusted完备级别，由于如许才不妨保护你只运用那些具备最新数据的去世视图；但是，被证明为精确（确凿任）的联系也可用来查问改写。在大普遍数据堆栈中，那些联系仍旧在索取、变换和加载（etl）进程获得了考证，所以不复须要举行考证。 分区变革盯梢 在oracle9i数据库中，oracle引入了分区变革盯梢（pct，partition change tracking）。运用这一个性，oracle9i数据库不妨盯梢去世视图的哪一局部对应于分区确定表的已革新局部。所以，即使查问不须要已革新表的局部，那么该去世视图仍旧不妨运用。 为了在去世视图中盯梢一个确定表的变革，必需对该表举行分区，而且该去世视图（在select列表中）必需囊括确定表的分区键或一个特出因变量：dbms_mview.pmarker。此因变量为确定表中的每个分区天生一个独一的操作符。 比方，由time_key对购买表举行分区。清单 第88中学创造的去世视图与前方运用的monthly_sales_mv 去世视图简直实足沟通，不过该去世视图在购买表上包括了一个附加的dbms_mview.pmarker因变量。经过包括这一因变量，当革新购买表时该去世视图承诺pct。提防：该去世视图自己并不须要被分区。 代码清单 8：具备dbms_mview.pmarker因变量的去世视图  create materialized view monthly_sales_pct_mv enable query rewrite as select dbms_mview.pmarker(ps.rowid) pm, t.month, p.product_id,        sum(ps.purchase_price) as sum_of_sales,        count (ps.purchase_price) as total_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id group by dbms_mview.pmarker(ps.rowid), t.month, p.product_id; 此刻，假如咱们向购买表中减少一个2003年4月的新分区，并且一个用户发出了一个乞求2002年3月的数据的查问，如清单 9所示。在此查问中，咱们并不关怀2003年4月已革新的数据，以是将运用去世图对其举行改写，纵然该去世视图仍旧作废也是如许。 代码清单 9：运用作废的去世视图举行查问改写  select t.month, p.product_id, sum(ps.purchase_price) from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       ps.time_key >= to_date(’01-03-2003’, ’dd-mm-yyyy’) and       ps.time_key <  to_date(’01-04-2003’, ’dd-mm-yyyy’)  group by t.month, p.product_id;   id    operation                       name               __________________________________________________    0    select statement                                     1     sort group by                                        2     mat_view rewrite access full    monthly_sales_pct_mv 即使查问诉求从1月至4月的数据，在orcale9i中，将不会为运用去世视图而对该查问举行改写。但在oracle数据库10g中，不妨运用monthly_sales_ pct_mv和确定表的贯串对该查问举行改写。 运用多个去世视图举行查问改写 前方已经提到，在oracle10g数据库中，查问改写仍旧获得了巩固，以是它不妨运用一个去世视图的局部数据以及确定表的其他数据来相应查问。究竟上，查问改写不妨贯串运用两个或多个去世视图。比方，假如你为每5年的数据价格保护一个独力的去世视图： monthly_sales_1990-1994、 monthly_sales_1995_to_2000、 monthly_sales_2001_to_2005，之类。 那么，对于须要从1993年至2003年数据的清单 第10中学的查问，查问改写不妨运用十足的三个去世视图。 代码清单 10  select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales, from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 1993 and 2003 group by t.month, p.product_id;   id    operation                        name               --------------------------------------------------------- 0 select statement                                     1    sort group by                                                  2     view                                                          3      union-all                                                     4       mat_view rewrite access full monthly_sales_2001_to_2005      5       mat_view rewrite access full monthly_sales_1995_to_2000      6       mat_view rewrite access full monthly_sales_1990_to_1994   代码清单 11 select t.month, p.product_id, sum(ps.purchase_price) as sum_of_sales from time t, product p, purchases ps where t.time_key = ps.time_key and       ps.product_id = p.product_id and       t.year between 1989 and 1999 group by t.month, p.product_id;   id    operation                        name               --------------------------------------------------------- 1 select statement                                     1    sort group by                                                  2     view                                                          3      union-all                                                  4 mat_view rewrite access full monthly_sales_1995_to_2000     5       mat_view rewrite access full monthly_sales_1990_to_1994     6       sort group by                                               7        nested loops                                               8         nested loops                                              9          table access full         time                          10          partition range iterator                                11           table access full        purchases                     12         index range scan           product_pk_index         清单 1第11中学的查问须要从1989年至1999年的数据，以是查问改写不妨运用去世视图monthly_sales_1990_to_1994和monthly_sales_1995_to_2000，并由确定表赢得1989年的数据。这一进程本质上会比由确定表中赢得一切数据更快少许。  oracle10g数据库在查问改写上面有其余几个矫正。在那些矫正中犯得着提防的是oracle10g数据库不妨更好地扶助汇合演算符（union、 unionall等）巩固了对多个表范例的查问的巩固，并供给了对分区变革盯梢中的list 和range-list分区典型的扶助。  东西 你大概会一面观赏正文，一面喃喃自语：“嗯，我想我领会了你的道理，但能否有某些东西不妨为我实行一切那些处事呢？”谜底是确定的。究竟上，那些东西还十分多。 oracle9i数据库援用了explain_mview和explain_rewrite。运用编制程序接口（api）explain_mview沿用一个去世视图设置，并倡导可运用何种典型的分区变革盯梢操纵、能否大概举行赶快革新，以及不妨实行何种典型的查问改写。当一个查问未被改写时，api explain_rewrite将报告你sql查问干什么不运用查问改写。在两种情景下，东西包城市报告你题目地方--比方，不许在一个一定列长进行贯穿，但两个包都不会精确报告你即使处置这个题目。这时候，就不妨运用包括在oracle10g数据库中的两个新东西--tune_mview和sql access advisor来扶助你处置这个题目。 tune_mview api将报告你怎样编写去世视图，使其不妨赶快革新，并不妨运用正文所刻画的尽大概多的高档查问改写典型。tune_mview api 的运用特殊大略：只须要将你的去世视图语句交给它，它就会判决该去世视图的最好情势。然而，即使你看到你的原始去世视图仍旧被变换为多个新本子，也不要感触怪僻。 让咱们来看看tune_mview 怎样不妨变换你的去世视图。假如咱们有一个大略的查问，并将其传播给explain_mview，如清单 12所示，确定该去世视图在暂时情势下能否不妨赶快革新。 代码清单 12  begin   dbms_mview.explain_mview(   ’create materialized view customer_mv    build immediate refresh fast enable query rewrite    as    select  c.customer_id, c.town,            count(distinct(product_id)) as dist_promo_cnt    from purchases ps, customer c    where ps.customer_id = c.customer_id    group by c.customer_id, c.town’, ’id1’);  end;  / -- see if refresh fast capability is allowed (y) or not (n) select capability_name, possible from mv_capabilities_table where capability_name = ’refresh_fast’ and statement_id = ’id1’; capability_name                p --------------------------------- refresh_fast                   n 此刻让咱们运用沟通的查问，并将其传播给tune_mview，如以次代码所示：  variable task_name varchar2(2000); begin dbms_advisor.tune_mview (:task_name, ’create materialized view customer_mv    build immediate refresh fast enable query rewrite    as    select  c.customer_id, c.town,            count(distinct(product_id)) as dist_promo_cnt    from purchases ps, customer c    where ps.customer_id = c.customer_id    group by c.customer_id, c.town’); end; / 代码清单 13 select statement from user_tune_mview where task_name = :task_name; create materialized view easydw.customer_mv  build immediate refresh fast with rowid  enable query rewrite as select easydw.purchases.product_id c1, easydw.customer.town c2,    easydw.customer.customer_id c3, count(*) m1 from easydw.purchases, easydw.customer where easydw.customer.customer_id = easydw.purchases.customer_id group by easydw.purchases.product_id, easydw.customer.town,          easydw.customer.customer_id;[page_break]目次视图user_tune_mview将表露所获得的去世视图，如清单 13所示。纵然它看起 来与咱们的原始去世视图有点各别，但在不妨运用原始去世视图的场合，仍旧不妨运用该 去世视图改写任何查问，其余，还不妨赶快革新。  你也不妨天生一个脚从来实行那些倡导，你大概蓄意做的仅有窜改即是变换去世视图的称呼，以及指定去世视图该当放在何处的保存语句和表空间。 此刻，咱们仍旧有了一个去世视图，但即使咱们不领会创造什么去世视图，那么该当如何办？这时候，sql access advisor不妨扶助你，由于它会欣赏你的体例，并它觉得须要的索引和去世视图。 那些倡导是鉴于本质的处事负载或按照你的形式所做出的假如提出的。当供给了sql语句的本质处事负载时，将获得最佳的截止。这一处事负载可由sql缓存的暂时实质、sql 调优汇合（tuning set）、oracle9i summary advisor处事负载或用户供给的处事负载表（包括你仍旧设置的sql语句）赢得。 sql access advisor既不妨经过吩咐行api运用，也不妨经过企业处置器（enterprise manager）的一局部--sql access advisor引导运用。运用该引导，在表露那些倡导之前只须要实行三个办法。让咱们来看看怎样常常吩咐行界面运用sql access advisor：  开始，创造一个包括，这一调优进程一切消息的工作。而后，该工作将运用处事负载消息来天生动作工作的一局部保存的调优倡导。所以，所有进程是实足独力的，并且承诺各个工作稍有各别，再不人们不妨看到对摆设举行窜改后的功效。在清单 14所示的示例中，是经过细工设置sql语句对处事负载举行设置的。 代码清单 14  declare task_desc     varchar2(100); task_id       number; task_name    varchar2(30); workload_name varchar2(30); begin    task_name := ’task_mag’;  dbms_advisor.create_task (dbms_advisor.sqlaccess_advisor,  task_id, task_name, ’my advisor task’,    dbms_advisor.sqlaccess_warehouse);  dbms_advisor.set_task_parameter (’task_mag’, ’evaluation_only’, ’false’);  dbms_advisor.set_task_parameter (’task_mag’, ’execution_type’, ’full’);  -- create the workload  workload_name :=’workload_mv’;  dbms_advisor.create_sqlwkld(workload_name, ’mv workload’ , null);  -- now link the two together  dbms_advisor.add_sqlwkld_ref(task_name, workload_name) ;  -- add a sql statement   dbms_advisor.add_sqlwkld_statement (workload_name,’app’,’action’,                                       null,15,3000,423,507,60,704,                                      3,’16-feb-2002’,80,                                      ’easydw’,    ’select  c.customer_id, c.town,            count(distinct(product_id)) as dist_promo_cnt     from purchases ps, customer c     where ps.customer_id = c.customer_id     group by c.customer_id, c.town’); end; / 一旦设置了处事负载和工作，就不妨天生如次所示的倡导，该倡导运用了execute_task 并指定了所创造工作的名字--task_mag： execute dbms_advisor.execute_task (’task_mag’); 按照处事负载的搀杂性，天生倡导的功夫不妨由几秒到几秒钟不等。所以，纵然这个进程不妨交互式运转，但你大概蓄意商量提交一个工作，这即是企业处置器中的引导所要实行的处事。 你不妨经过查问表user_advisor_recommendations 来赶快查看能否相关于task_name的倡导。在对本例举行此操纵时，咱们会看到仍旧提出了一个倡导。  select ’no of recommendations:’ , count(*)   from user_advisor_recommendations r      where task_name=’task_mag’; ’noofrecommendations:’   count(*) ---------------------- ---------- no of recommendations:          1 单个倡导不妨引导多个操纵。对于此示例，sql access advisor倡导创造去世视图日记、一个create materialized view，以及一个用来领会去世视图的挪用（受版面控制，这边未给出）。 纵然你不妨查问百般目次视图来察看那些操纵，但察看它们的最简片面法即是天生一个剧本，如次所示：  execute dbms_advisor.create_file(dbms_advisor.get_task_script(’task_mag’),  ’advisor_results’, ’mag_example.sql’); 在清单 1第5中学，你不妨看到该剧本的一段节录，表露了为咱们的查问所创造的去世视图。 代码清单 15  rem  access advisor  rem rem  username:        easydw rem  task:            my_task rem  execution date:  20/05/2003 14:36 rem ... create materialized view "easydw"."mv$$_002d0000" refresh fast with rowid enable query rewrite as select easydw.purchases.product_id c1,           easydw.customer.town c2,           easydw.customer.customer_id c3, count(*) m1    from easydw.purchases, easydw.customer    where easydw.customer.customer_id = easydw.purchases.customer_id    group by easydw.purchases.product_id, easydw.customer.town,             easydw.customer.customer_id; ... 论断 经过运用查问改写，你不妨运用几个去世视图明显矫正很多查问的本能，进而缩小了维持去世视图与普通确定数据同步所须要的磁盘空间占用与革新功夫