데이터 베이스 MySQL 튜토리얼 详述Oracle 11g中的Reference Partition

详述Oracle 11g中的Reference Partition

Jun 07, 2016 pm 03:57 PM

本篇主要介绍11g新推出的Reference Partitioin。Reference Partition针对的业务场景是主外键关联。主表分区之后,借助Reference

Data Partition是Oracle早期提出的一项针对大数据对象的解决方案。经过若干版本的演变,Partition依然是目前比较流行、应用广泛并且接受程度较高的技术策略。

从Oracle产品线角度,Partition的成功是与Oracle不断丰富完善分区技术和方案是分不开的。在每一个版本中,Partition技术都推出一些新的进步和发展。无论是8、8i还是11g、12c,Partition技术都是在不断的向前进步,来满足更加复杂的实际应用需求。

本篇主要介绍11g新推出的Reference Partitioin。Reference Partition针对的业务场景是主外键关联。主表分区之后,借助Reference Partition可以实现自动的子表分区(不管子表上有无分区键)。经过Reference Partition分区之后,在同一个主表分区中的数据记录,对应到的子表记录,全部都在相同的子表分区上。

这种特性和分区类型,从性能和管理两个方面,都可以给日常运维带来很多好处方便。下面笔者将通过一系列实验来介绍Reference Partiton。

1、实验环境介绍

笔者选择Oracle 11g进行测试,,具体版本为11.2.0.4。

SQL> select * from v$version;

BANNER

-----------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE    11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

2、Reference Partition数据表创建

和普通主外键数据表创建没有过多差异,首先我们需要创建带分区的主表。

SQL> create table t_master

  2  ( object_id number,

  3    owner varchar2(100),

  4    object_name varchar2(100),

  5    object_type varchar2(100)

  6  )

  7  partition by list(owner) –List分区类型

  8  (

  9    partition p0 values ('PUBLIC'),

 10    partition p1 values ('SYS'),

 11    partition p3 values (default)

 12  )

 13  ;

--添加主键约束

SQL> alter table t_master add constraint pk_t_master primary key (object_id);

Table altered

创建子表,注意:Reference Partition并不要求子表中包括分区键,引用关系就是子表的分区依据。另外:使用Reference Partition要求创建子表和定义外键约束在同一个语句中。

SQL> create table t_detail

  2  ( object_id number,

  3    master_id number,

  4    obj_comment varchar2(100),

  5    obj_type varchar2(100),

  6    constraint fk_mas_det foreign key (master_id) references t_master(object_id)

  7  ) partition by reference(fk_mas_det);

 

create table t_detail

( object_id number,

  master_id number,

  obj_comment varchar2(100),

  obj_type varchar2(100),

  constraint fk_mas_det foreign key (master_id) references t_master(object_id)

) partition by reference(fk_mas_det)

ORA-14652: 不支持引用分区外键

我们收到了一个Oracle报错。首先我们看一下定义reference partition的语法,在create table语句中要创建定义好外键约束的名称。之后,利用partition by语句,将外键作为划分依据进行定义。

当前报错ORA-14652,检查一下官方对于这个错误的解释。

[oracle@localhost ~]$ oerr ora 14652

14652, 00000, "reference partitioning foreign key is not supported"

// *Cause:  The specified partitioning foreign key was not supported

//          for reference-partitioned tables. All columns of the

//          partitioning foreign key must be constrained NOT NULL with

//          enabled, validated, and not deferrable constraints. Furthermore,

//          a virtual column cannot be part of the partitioning foreign key.

//* Action: Correct the statement to specify a supported

//          partitioning foreign key.

说明中提示了错误原因,如果使用Reference Partition,外键列是不允许为空的。标准外键定义并没有规定外键列必须为空,但是如果使用引用分区技术,就必须要求外键列不能为空。

这种约束其实也好理解。Reference Partition不需要明确指定分区键,但是实际上还是需分区键(或者称为分区因素)。如果没有外键值,也就失去了到主表分区的定位功能,Oracle必然不会允许创建。修改建表语句如下:

SQL> create table t_detail

  2  ( object_id number,

  3    master_id number not null,

  4    obj_comment varchar2(100),

  5    obj_type varchar2(100),

  6    constraint fk_mas_det foreign key (master_id) references t_master(object_id)

  7  ) partition by reference(fk_mas_det);

Table created

下面从分区表角度观察两个数据表。

SQL> select partition_name, high_value, partition_position from dba_tab_partitions where table_owner='SYS' and table_name='T_MASTER';

PARTITION_NAME      HIGH_VALUE      PARTITION_POSITION

-------------------- --------------- ------------------

P0                  'PUBLIC'                        1

P1                  'SYS'                            2

P3                  default                          3

SQL> select partition_name, high_value, partition_position from dba_tab_partitions where table_owner='SYS' and table_name='T_DETAIL';

PARTITION_NAME      HIGH_VALUE      PARTITION_POSITION

-------------------- --------------- ------------------

P0                                                    1

P1                                                    2

P3                                                    3

注意两点:子表t_detail的high_value列为空,说明该数据表并没有一个明确的分区键,主表分区键owner在子表中也不存在。另外,子表分区结构、数量和名称与主表完全相同。

从段结构segment上,我们可以看到11g的defered segment creation并没有应用。

SQL> select segment_name, partition_name, segment_type from dba_segments where owner='SYS' and segment_name in ('T_MASTER','T_DETAIL');

SEGMENT_NAME    PARTITION_NAME      SEGMENT_TYPE

--------------- -------------------- ----------------------

T_MASTER        P3                  TABLE PARTITION

T_MASTER        P1                  TABLE PARTITION

T_MASTER        P0                  TABLE PARTITION

T_DETAIL        P3                  TABLE PARTITION

T_DETAIL        P1                  TABLE PARTITION

T_DETAIL        P0                  TABLE PARTITION

6 rows selected

3、数据插入实验

下面进行数据插入和分区分布实验。首先进行主表数据插入:

SQL> insert into t_master select object_id, owner, object_name, object_type from dba_objects;

120361 rows inserted

SQL> commit;

Commit complete

SQL> exec dbms_stats.gather_table_stats(user,'T_MASTER',cascade => true);

PL/SQL procedure successfully completed

子表数据插入:

SQL> insert into t_detail select seq_t_detail.nextval, object_id, object_name, object_type from dba_objects where object_name not in 

('SEQ_T_DETAIL');

120361 rows inserted

SQL> commit;

Commit complete

SQL> exec dbms_stats.gather_table_stats(user,'T_DETAIL',cascade => true);

PL/SQL procedure successfully completed

按照当前的数据关系,应该是一条主表记录,对应一条子表记录的关系。我们检查数据字典情况。

SQL> select table_name, partition_name, high_value,num_rows from dba_tab_partitions where table_owner='SYS' and table_name in ('T_MASTER');

TABLE_NAME        PARTITION_NAME      HIGH_VALUE        NUM_ROWS

------------------------------ -------------------- --------------- ----------

T_MASTER          P0                  'PUBLIC'            33996

T_MASTER          P1                  'SYS'                37817

T_MASTER          P3                  default              48548

SQL> select table_name, partition_name, high_value,num_rows from dba_tab_partitions where table_owner='SYS' and table_name in ('T_DETAIL');

TABLE_NAME        PARTITION_NAME      HIGH_VALUE        NUM_ROWS

------------------------------ -------------------- --------------- ----------

T_DETAIL          P0                                        33996

T_DETAIL          P1                                        37817

T_DETAIL          P3                                        48548

数据分布正确。说明:子表分区分布的依据完全在于主表记录对应的分区编号。相同主表分区记录对应的子表记录,一定在相同的子表分区上。不同主表分区记录对应的子表记录,不可能在相同的子表分区上。

为便于实验,多插入一些数据:

SQL> insert into t_detail select seq_t_detail.nextval, object_id, object_name, object_type from dba_objects where object_name not in 

('SEQ_T_DETAIL');

120361 rows inserted

SQL> commit;

Commit complete

SQL> exec dbms_stats.gather_table_stats(user,'T_DETAIL',cascade => true);

PL/SQL procedure successfully completed

SQL> select table_name, partition_name, high_value,num_rows from dba_tab_partitions where table_owner='SYS' and table_name in ('T_DETAIL');

TABLE_NAME    PARTITION_NAME      HIGH_VALUE        NUM_ROWS

------------------------------ -------------------- --------------- ----------

T_DETAIL      P0                                        67992

T_DETAIL      P1                                        75634

T_DETAIL      P3                                        97096

那么,Reference Partition在实际运维场景下的意义在于何处呢?

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
WWE 2K25 : Myrise에서 모든 것을 잠금 해제하는 방법
1 몇 달 전 By 尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

Alter Table 문을 사용하여 MySQL에서 테이블을 어떻게 변경합니까? Alter Table 문을 사용하여 MySQL에서 테이블을 어떻게 변경합니까? Mar 19, 2025 pm 03:51 PM

이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

InnoDB 전체 텍스트 검색 기능을 설명하십시오. InnoDB 전체 텍스트 검색 기능을 설명하십시오. Apr 02, 2025 pm 06:09 PM

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

MySQL 연결에 대한 SSL/TLS 암호화를 어떻게 구성합니까? MySQL 연결에 대한 SSL/TLS 암호화를 어떻게 구성합니까? Mar 18, 2025 pm 12:01 PM

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

인기있는 MySQL GUI 도구는 무엇입니까 (예 : MySQL Workbench, Phpmyadmin)? 인기있는 MySQL GUI 도구는 무엇입니까 (예 : MySQL Workbench, Phpmyadmin)? Mar 21, 2025 pm 06:28 PM

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

MySQL에서 큰 데이터 세트를 어떻게 처리합니까? MySQL에서 큰 데이터 세트를 어떻게 처리합니까? Mar 21, 2025 pm 12:15 PM

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.

InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. Apr 02, 2025 pm 06:25 PM

클러스터 인덱스와 비 클러스터 인덱스의 차이점은 1. 클러스터 된 인덱스는 인덱스 구조에 데이터 행을 저장하며, 이는 기본 키 및 범위별로 쿼리에 적합합니다. 2. 클러스터되지 않은 인덱스는 인덱스 키 값과 포인터를 데이터 행으로 저장하며 비 예산 키 열 쿼리에 적합합니다.

드롭 테이블 문을 사용하여 MySQL에서 테이블을 어떻게 드롭합니까? 드롭 테이블 문을 사용하여 MySQL에서 테이블을 어떻게 드롭합니까? Mar 19, 2025 pm 03:52 PM

이 기사에서는 Drop Table 문을 사용하여 MySQL에서 테이블을 떨어 뜨리는 것에 대해 설명하여 예방 조치와 위험을 강조합니다. 백업 없이는 행동이 돌이킬 수 없으며 복구 방법 및 잠재적 생산 환경 위험을 상세하게합니다.

MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? Apr 09, 2025 am 12:05 AM

전체 테이블 스캔은 MySQL에서 인덱스를 사용하는 것보다 빠를 수 있습니다. 특정 사례는 다음과 같습니다. 1) 데이터 볼륨은 작습니다. 2) 쿼리가 많은 양의 데이터를 반환 할 때; 3) 인덱스 열이 매우 선택적이지 않은 경우; 4) 복잡한 쿼리시. 쿼리 계획을 분석하고 인덱스 최적화, 과도한 인덱스를 피하고 정기적으로 테이블을 유지 관리하면 실제 응용 프로그램에서 최상의 선택을 할 수 있습니다.

See all articles