在进行连接时改进搜索.集群表？

Question

假设我们有三张桌子:
-Buildings
-Rooms
-People

建筑物可以有1到30个房间(比如说平均值是3个)
而建筑物可以有0到30个人(平均3个)
一个房间和一个人只能属于一个单独的建筑物.

每个月我们都会在我们的数据库中添加约50,000个新建筑物及其房间和人员.
我们可以删除超过2年的数据,因此我们将拥有大约1.2M的建筑行.

主要问题是我们想要搜索并返回通常(但不总是)包含至少两个表(建筑物始终存在)的数据,因此我们必须执行连接.

我研究了3个解决方案

• 标准化数据(由于连接和低可伸缩性导致的低性能)
• 在Rooms和People表中复制建筑数据.(快但我一般不喜欢非规范化)
• Oracle集群表.(似乎提供了良好的性能和数据仍然正常化)

所以问题是:
Oracle Cluster是否适合这种情况？
是否可以连续向这样的群集添加行？
如果你不推荐Cluster,为什么以及什么更适合？

细节:

簇:

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_C R
  INNER JOIN PEOPLE_C C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_C S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--17 consistent gets

标准化:

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_N R
  INNER JOIN PEOPLE_N C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_N S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--44 consistent gets

Answer 1

聚类是一种存储密切相关且通常连接在一起的磁盘上相同区域的表的方法.群集密钥是一列或多列,通过这些列,表通常在查询中连接以保存在IO上.但是,如果单个群集行中所有表行的总大小将超过磁盘块的大小,那么您将最终处于链接状态,并且有一天,您将失去群集的所有优点.在我看来,更好的避免,因为它将是一个开销,因为你有一个1.2 M的滚动量,一个集群中的所有3个表明显会对HWM产生影响.

最好去JOINS.

例如.

CREATE TABLE BUILDING_C ( BUILDING_ID NUMBER PRIMARY KEY,
                     ADDRESS_FIELD VARCHAR2 ( 25 ) );

CREATE TABLE PEOPLE_C ( BUILDING_ID NUMBER PRIMARY KEY,
                    CUSTOMER_ID NUMBER,
                    ROOM_ID NUMBER,
                    CUSTOMER_DETAILS VARCHAR2 ( 25 ) );

CREATE TABLE ROOM_C ( BUILDING_ID NUMBER PRIMARY KEY,
                  ROOM_ID NUMBER,
                  OPEN_DATE DATE,
                  CURRENT_OCCUPANCY CHAR ( 1 ) );

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'BUILDING_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'PEOPLE_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'ROOM_C',
                            NUMROWS  => 20000000 );
END;
/

在您的查询中,您的提示将不会生效,因为您已经使用SELECT * /*+ FIRST_ROWS(200)*/而不是SELECT /*+ FIRST_ROWS(200)*/ *因此您最终在OPTIMIZER MODE = ALL_ROWS而不是OPTIMIZER MODE = FIRST_ROWS

SET AUTOTRACE ON

SELECT
      *
FROM
      (SELECT
            /*+ FIRST_ROWS(200)*/
            *
       FROM
            BUILDING_C R
            INNER JOIN PEOPLE_C C
                ON ( R.BUILDING_ID = C.BUILDING_ID )
            INNER JOIN ROOM_C S
                ON ( S.BUILDING_ID = R.BUILDING_ID )
       WHERE
            S.OPEN_DATE >=   SYSDATE - 60 - 1
            AND S.OPEN_DATE <= SYSDATE - 60
       ORDER BY
            S.OPEN_DATE)
WHERE
      ROWNUM < 200;


Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=HINT: FIRST_ROWS (Cost=54189 Card=199 Bytes=38 K)
   1    0    COUNT STOPKEY
   2    1      VIEW (Cost=54189 Card=50 K Bytes=9 M)
   3    2        SORT ORDER BY STOPKEY (Cost=54189 Card=50 K Bytes=9 M)
   4    3          FILTER
   5    4            NESTED LOOPS
   6    5              NESTED LOOPS (Cost=52041 Card=50 K Bytes=9 M)
   7    6                MERGE JOIN (Cost=2020 Card=50 K Bytes=5 M)
   8    7                  TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.BUILDING_C (Cost=826 Card=20 M Bytes=1G)
   9    8                    INDEX FULL SCAN REALSPIRITUALS.SYS_C00504893 (Cost=26 Card=20 M)
  10    7                  SORT JOIN (Cost=1194 Card=50 K Bytes=1 M)
  11   10                    TABLE ACCESS FULL REALSPIRITUALS.ROOM_C (Cost=660 Card=50 K Bytes=1 M)
  12    6                INDEX UNIQUE SCAN REALSPIRITUALS.SYS_C00504894 (Cost=0 Card=1)
  13    5              TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.PEOPLE_C (Cost=1 Card=1 Bytes=91)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  spare statistic 3
          0  gcs messages sent
          0  db block gets from cache
          0  physical reads direct (lob)
          0  queue position update
          0  queue single row
          0  queue ocp pages
          0  HSC OLTP Compressed Blocks
          0  HSC IDL Compressed Blocks
          0  rows processed

建议:

1. 在OPEN_DATE列上使用索引
2. 如果需要,使用并行提示加速/*+ parallel(table,n)*/
3. 尝试范围分区