Updating Partition Views

How can I update two identically tables through a view :
Table user1.table (col1,col2,col3) - check constraint col1=1 - PK on col1+col2 - index on col1
Table user2.table (col1,col2,col3) - check constraint col1=2 - PK on col1+col2 - index on col1 (GRANT ALL ON user1 to this Table)
View user1.table_all : Select * from user1.table union all Select * from user2.table
SELECT * FROM USER_UPDATABLE_COLUMNS WHERE TABLE_NAME='TABLE_ALL' => no del/ins/upd permitted on this view.
If somebody 's got something...
Thanks

bof bof...
Solution is a bit expensive - cause no confusion could append due to Check Constraint...
Thanks a lot.
[email protected]

Similar Messages

  • (V7.3) PARTITION VIEW 테스트 REPORT

    제품 : ORACLE SERVER
    작성날짜 : 2004-08-13
    SCOPE
    8~10g Standard Edition 에서는 Partitioning Option 은 지원하지 않습니다.
    1. 개요
    대용량 Database를 구축하고 관리하는 데 있어서 필연적으로 나타날 수 있는
    문제는 시간적 증가 또는 지역적으로 확대됨에 따라 어느 TABLE의 SIZE가
    증가함에 따라 이에 따른 관리 방법의 효율화일 것이다.
    이는 주기적인 재편성(Re-Organization) 뿐만 아니라 Backup, Index의 비대화
    등에 따른 Query의 효율 저하 등 여러가지 문제를 야기시킬 수 있다.
    이에 대한 해결책인 Partition View(Ver.7.3 이상)를 실무적용 사례를 통해서
    구축방법, Partition View의 효율적 사용방법, 주의할 점 등을 알아보고자 한다.
    2. 구축과정
    1) Partition View를 위한 Parameter
    init$ORACLE_SID.ora 화일에 다음의 Parameter를 Setting
    partition_view_enabled=TRUE
    2) Partition View 대상 Table 및 Partition Column을 선정
    이는 물리적 설계 시 결정
    Partition Column의 주요 후보는 일시, 지역 등 명확히 구분되는
    Column이어야 함
    3) Table Create --> Partition Column에 반드시 해당 범위의 Check
    Constraint를 반드시 주어야 함.
    ( 주의 사항 )
    Partition Column의 DATATYPE을 CHAR로 하지 말 것
    (BUG) --> VARCHAR2 사용 ( BUG로 등록되어 있음 )
    Partition View를 구성하는 모든 Table Scheme는 완전히 동일해야 함
    (Column의 갯수, Datatype, Null허용 여부 등)
    실제로 비씨카드에서 TYPE의 불일치로 문제가 발생했었음.
    1996.01월 Table(TBCARDUSE_199601)의 한 Column의 Type이 다른
    Table은 모두 VARCHAR(9)였는데 이 Table만 VARCHAR2(10)로
    되어 있어서 Partition View를 JOIN하면 VIEW 내의 모든 TABLE이
    FULL TABLE SCAN을 함. DATATYPE을 동일하게 해준 후 정상적으로
    동작
    4) Index Create --> 모든 Table이 반드시 동일한 Index를 가져야 함.
    Partition Column에 Index가 반드시 필요한 것은 아님.
    5) 각 Table에 ANALYZE TABLE을 수행(가능한 한 COMPUTE STATISTICS로)
    6) Partition 내의 모든 Table을 UNION ALL 한 Partition View를 생성
    3. 구축 사례
    TBCARDUSE_199507 - TBCARDUSE_199609 ( 15개 Table )
    각 Table의 예상 Row 수는 최소 1,200 만 이상으로 15개월을 보관함을
    원칙으로 하여 총 Row는 2억건 정도이다.
    CREATE TABLE TBCARDUSE_199507
    (USE_NO varchar2(8) not null,
    CARD_NO varchar2(16) not null,
    REQ_REJ_CLSS char(1) not null,
    LO_AB_CLSS char(1) not null,
    MER_MGMT_NO varchar2(9) not null,
    AUTH_CLSS char(2) not null,
    AUTH_DATE varchar2(8) not null,->Partition Column
    AUTH_TIME char(6) not null,
    AUTH_AMT number(13,2) not null,
    EN_MODE char(2) not null,
    AUTH_REQ_MTHD char(2) not null,
    AUTH_REQ_CLSS char(1) not null,
    SALE_REF_PL char(2) ,
    REQ_MER_MGMT_NO varchar2(9) ,
    SALE_PL_NO varchar2(12) ,
    REQ_VALD_LIM char(6) ,
    USE_AMT number(11) ,
    RCP_AMT number(11) ,
    MER_RCP_FEE number(11) ,
    RCP_DATE char(8) ,
    POS_CODE char(2) ,
    CONSTRAINT C_AUTH_DATE_199507
    CHECK (AUTH_DATE BETWEEN '19950701' AND '19950731'))
    ---> Partition Column Constraint
    TABLESPACE TS_TUNING01
    PCTFREE 10
    STORAGE(INITIAL 100M NEXT 100M PCTINCREASE 0
    MAXEXTENTS UNLIMITED FREELISTS 10);
    * Index 정보
    Index 1 : CARD_NO
    CREATE INDEX TBCARDUSE_199507_IDX1
    ON TBCARDUSE_199507(CARD_NO)
    TABLESPACE TS_TUNING_I01
    STORAGE(INITIAL 50M NEXT 50M PCTINCREASE 0
    MAXEXTENTS UNLIMITED)
    PARALLEL (DEGREE 4);
    Index 2 : USE_NO
    CREATE INDEX TBCARDUSE_199507_IDX2
    ON TBCARDUSE_199507(USE_NO)
    TABLESPACE TS_TUNING_I01
    STORAGE(INITIAL 50M NEXT 50M PCTINCREASE 0
    MAXEXTENTS UNLIMITED)
    PARALLEL (DEGREE 4);
    Index 3 : AUTH_DATE + MER_MGMT_NO
    CREATE INDEX TBCARDUSE_199507_IDX3
    ON TBCARDUSE_199507(AUTH_DATE,MER_MGMT_NO)
    TABLESPACE TS_TUNING_I01
    STORAGE(INITIAL 50M NEXT 50M PCTINCREASE 0
    MAXEXTENTS UNLIMITED)
    PARALLEL (DEGREE 4);
    Index 4 : MER_MGMT_NO + AUTH_DATE
    CREATE INDEX TBCARDUSE_199507_IDX4
    ON TBCARDUSE_199507(MER_MGMT_NO, AUTH_DATE)
    TABLESPACE TS_TUNING_I01
    STORAGE(INITIAL 50M NEXT 50M PCTINCREASE 0
    MAXEXTENTS UNLIMITED)
    PARALLEL (DEGREE 4);
    * Table Analyzing
    analyze table TBCARDUSE_199507 compute statistics;
    * Partition View Creation
    CREATE OR REPLACE VIEW PV_TBCARDUSE
    AS
    SELECT * FROM TBCARDUSE_199507
    UNION ALL
    SELECT * FROM TBCARDUSE_199508
    UNION ALL
    SELECT * FROM TBCARDUSE_199509
    UNION ALL
    SELECT * FROM TBCARDUSE_199510
    UNION ALL
    SELECT * FROM TBCARDUSE_199511
    UNION ALL
    SELECT * FROM TBCARDUSE_199512
    UNION ALL
    SELECT * FROM TBCARDUSE_199601
    UNION ALL
    SELECT * FROM TBCARDUSE_199602
    UNION ALL
    SELECT * FROM TBCARDUSE_199603
    UNION ALL
    SELECT * FROM TBCARDUSE_199604
    UNION ALL
    SELECT * FROM TBCARDUSE_199605
    UNION ALL
    SELECT * FROM TBCARDUSE_199606
    UNION ALL
    SELECT * FROM TBCARDUSE_199607
    UNION ALL
    SELECT * FROM TBCARDUSE_199608
    UNION ALL
    SELECT * FROM TBCARDUSE_199609
    4. Test Procedure
    1) Partition View의 동작 여부 확인
    (1) Partition Column이 '='로 비교 되었을 때
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE USE_NO = '00002037'
    AND AUTH_DATE = '19960723';
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    1 VIEW OF 'PV_TBCARDUSE'
    1 UNION-ALL (PARTITION)
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199507'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199507_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199508'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199508_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199509'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199509_IDX2'
    0 FILTER ---> Access 불 필요 Skip Operation
    0 TABLE ACCESS OF 'TBCARDUSE_199510'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199511'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199511_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199512'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199512_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199601'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199601_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199602'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199602_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199603'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199603_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199604'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199604_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199605'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199605_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199606'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199606_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199607'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199607_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199608'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199608_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199609'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199609_IDX2'
    ( 설명 ) Partition View의 가장 일반적인 사용 Case로 Partition
    Column이 *=*로 비교 되었을 때는 Access 불 필요
    Table은 Skip하는 Operation (FILTER)이 동작 함.
    (2) Partition Column이 " BETWEEN ~ AND ~ "로 비교 될 때
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE USE_NO = '00002037'
    AND AUTH_DATE BETWEEN '19960701' AND '19960731'
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    1 VIEW OF 'PV_TBCARDUSE'
    1 UNION-ALL (PARTITION)
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199507'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199507_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199508'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199508_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199509'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199509_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199510'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199511'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199511_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199512'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199512_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199601'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199601_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199602'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199602_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199603'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199603_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199604'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199604_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199605'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199605_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199606'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199606_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199607'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199607_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199608'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199608_IDX2'
    0 FILTER
    0 TABLE ACCESS OF 'TBCARDUSE_199609'
    0 INDEX (RANGE SCAN) OF 'TBCARDUSE_199609_IDX2'
    ( 설명 ) Partition Column이 BETWEEN~AND~ 로 비교 되었을 때는
    Access 불 필요 Table은 Skip하는 Operation(FILTER)이
    동작 함
    (3) Partition Column이 " LIKE "로 비교 될 때
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE USE_NO = '00002037'
    AND AUTH_DATE LIKE '199607%'
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    1 VIEW OF 'PV_TBCARDUSE'
    1 UNION-ALL (PARTITION)
    0 TABLE ACCESS OF 'TBCARDUSE_199507'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199508'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199509'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199510'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199511'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199511_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199512'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199512_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199601'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199601_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199602'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199602_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199603'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199603_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199604'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199604_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199605'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199605_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199606'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199606_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199607'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199607_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199608'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199608_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199609'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199609_IDX2'
    ( 설명 ) Partition Column이 LIKE로 비교 되었을 때는
    FILTER가 동작하지 않음. (주의 요망)
    (4) Partition Column이 " OR "로 비교 될 때
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE USE_NO = '00002037'
    AND ( AUTH_DATE BETWEEN '19960601' AND '19960630'
    OR AUTH_DATE BETWEEN '19960701' AND '19960730')
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    1 VIEW OF 'PV_TBCARDUSE'
    1 UNION-ALL (PARTITION)
    0 TABLE ACCESS OF 'TBCARDUSE_199507'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199508'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199509'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199510'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199510_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199511'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199511_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199512'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199512_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199601'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199601_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199602'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199602_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199603'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199603_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199604'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199604_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199605'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199605_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199606'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199606_IDX2'
    1 TABLE ACCESS OF 'TBCARDUSE_199607'
    2 INDEX (RANGE SCAN) OF 'TBCARDUSE_199607_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199608'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199608_IDX2'
    0 TABLE ACCESS OF 'TBCARDUSE_199609'
    1 INDEX (RANGE SCAN) OF 'TBCARDUSE_199609_IDX2'
    ( 설명 ) Partition Column이 OR로 비교 되었을 때는
    FILTER가 동작하지 않음. ( BUG로 등록되어 있음 )
    (5) Partition Column이 " BETWEEN "으로 비교되고 다른 비교
    Column이 없을 때
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE AUTH_DATE BETWEEN '19960601' AND '19960630'
    EXECUTION PLAN
    SELECT STATEMENT
    VIEW PV_TBCARDUSE
    UNION-ALL (PARTITION)
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199507
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199508
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199509
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199510
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199511
    INDEX (RANGE SCAN) TBCARDUSE_199511_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199512
    INDEX (RANGE SCAN) TBCARDUSE_199512_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199601
    INDEX (RANGE SCAN) TBCARDUSE_199601_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199602
    INDEX (RANGE SCAN) TBCARDUSE_199602_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199603
    INDEX (RANGE SCAN) TBCARDUSE_199603_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199604
    INDEX (RANGE SCAN) TBCARDUSE_199604_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199605
    INDEX (RANGE SCAN) TBCARDUSE_199605_IDX3
    TABLE ACCESS FULL TBCARDUSE_199606
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199607
    INDEX (RANGE SCAN) TBCARDUSE_199607_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199608
    INDEX (RANGE SCAN) TBCARDUSE_199608_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199609
    INDEX (RANGE SCAN) TBCARDUSE_199609_IDX3
    (6) Partition Column이 " OR "로 비교되고 다른 비교 Column이
    없을 때.
    SELECT CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE AUTH_DATE BETWEEN '19960501' AND '19960531'
    OR AUTH_DATE BETWEEN '19960601' AND '19960630'
    OR AUTH_DATE BETWEEN '19960701' AND '19960731'
    EXECUTION PLAN
    SELECT STATEMENT
    VIEW PV_TBCARDUSE
    UNION-ALL (PARTITION)
    TABLE ACCESS FULL TBCARDUSE_199507
    TABLE ACCESS FULL TBCARDUSE_199508
    TABLE ACCESS FULL TBCARDUSE_199509
    TABLE ACCESS FULL TBCARDUSE_199510
    TABLE ACCESS FULL TBCARDUSE_199511
    TABLE ACCESS FULL TBCARDUSE_199512
    TABLE ACCESS FULL TBCARDUSE_199601
    TABLE ACCESS FULL TBCARDUSE_199602
    TABLE ACCESS FULL TBCARDUSE_199603
    TABLE ACCESS FULL TBCARDUSE_199604
    TABLE ACCESS FULL TBCARDUSE_199605
    TABLE ACCESS FULL TBCARDUSE_199606
    TABLE ACCESS FULL TBCARDUSE_199607
    TABLE ACCESS FULL TBCARDUSE_199608
    TABLE ACCESS FULL TBCARDUSE_199609
    # 최악의 경우
    (7) 위 (6)의 Query를 " BETWEEN "으로 변환 경우
    SELECT /*+ FULL(PV_TBCARDUSE) */
    CARD_NO,USE_NO,AUTH_DATE,AUTH_AMT
    FROM PV_TBCARDUSE
    WHERE AUTH_DATE BETWEEN '19960501' AND '19960731'
    EXECUTION PLAN
    SELECT STATEMENT
    VIEW PV_TBCARDUSE
    UNION-ALL (PARTITION)
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199507
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199508
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199509
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199510
    INDEX (RANGE SCAN) TBCARDUSE_199510_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199511
    INDEX (RANGE SCAN) TBCARDUSE_199511_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199512
    INDEX (RANGE SCAN) TBCARDUSE_199512_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199601
    INDEX (RANGE SCAN) TBCARDUSE_199601_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199602
    INDEX (RANGE SCAN) TBCARDUSE_199602_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199603
    INDEX (RANGE SCAN) TBCARDUSE_199603_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199604
    INDEX (RANGE SCAN) TBCARDUSE_199604_IDX3
    TABLE ACCESS FULL TBCARDUSE_199605
    TABLE ACCESS FULL TBCARDUSE_199606
    TABLE ACCESS FULL TBCARDUSE_199607
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199608
    INDEX (RANGE SCAN) TBCARDUSE_199608_IDX3
    FILTER
    TABLE ACCESS (BY ROWID) OF TBCARDUSE_199609
    INDEX (RANGE SCAN) TBCARDUSE_199609_IDX3
    2) Insert, Delete, Update의 사용
    현재까지는 Partition View에 직접적으로 Insert/Delete/Update를
    할 수 없다.
    (이는 8.0 Version에 가능] 따라서 현재는 2 가지 방법으로 가능.
    (1) DYNAMIC SQL을 이용하는 방법
    (2) LOGIC적으로 IF-ELSE 방법을사용하여 가능한 일어 날 수 있는 모든
    경우를 기술하는 방법
    (비교) (1)의 방법은 Application 작성이 간단하기는 하나 LOOP안에서
    수행되거나 빈번히 수행되는 경우에는 Parsing Overhead가
    심각해 질 정도로 증가 됨.
    (2)의 방법은 (1)의 단점을 해소 할 수 있으나 Partition
    Table이 추가, 변경됨 따라 주기적으로 APPLICATION이 같이
    변경해 주어야 한다.
    3) Partition View의 효율적인 사용 방법
    (1) Parsing Time의 감소
    Partition View는 많은 수의 Table을 UNION ALL View로 만든
    것이므로 Query 수행 시 Parsing Time의 Overhead로 인해 성능
    저하를 가져 올 수 있다.
    이에 대해서 물리적인 방법(HOLD_CURSOR,
    CURSOR_SPACE_FOR_TIME=true 등)으로 Re-Parsing Time을 줄일
    수 있으나 Partion View를 효율적으로 생성하므로써 Overhead를
    줄일 수 있다.
    (가) 수직적 분할
    (사례)에서는 약 100개 정도의 Column에 대해서 "Select * "의
    형태로 되어 있어 Data Dictionary Call이 그만큼 많아 진다.
    그러나 Table의 속성을 보면 필수 NOT NULL Column(10ro)을
    제외한 90개의 Column이 실제적으로는 '신용판매','현금서비스',
    '해외이용'의 3가지로 GROUPING 되는 것으로 PARTITION VIEW
    자체를 3개 정도로 분할(수직적인 분할)하고 사용하여 Overhead
    를 줄인다.
    (나) 수평적 분할
    가장 ACTIVE한 범위를 정하여 수평적으로 분할하여 Partition
    View를 생성한다.
    (사례)에서는 3개월,6개월,9개월 단위의 Partition View를
    만들어 사용하고 있다.
    (2) Partition Column이 비교절에 나오지 않을때
    이 때는 어쩔 수 없이 Partition Column이 사용 될 수 없으므로
    일반적인 UNION-ALL View형태로 Access 될 수 밖에 없다. 그러나
    SELECT 결과가 1건일 경우에는 ROWNUM 제한을 시켜 될 수 있는 한
    TABLE ACCESS를 제한시킨다.
    ( UNION ALL의 순서를 역순으로 하여 VIEW를 생성 )
    CREATE OR REPLACE VIEW PV_TBCARDUSE1
    AS
    SELECT * FROM TBCARDUSE_199609
    UNION ALL
    SELECT * FROM TBCARDUSE_199608
    UNION ALL
    SELECT * FROM TBCARDUSE_199607
    UNION ALL
    SELECT * FROM TBCARDUSE_199606
    UNION ALL
    SELECT * FROM TBCARDUSE_199605
    UNION ALL
    SELECT * FROM TBCARDUSE_199604
    UNION ALL
    SELECT * FROM TBCARDUSE_199603
    UNION ALL
    SELECT * FROM TBCARDUSE_199602
    UNION ALL
    SELECT * FROM TBCARDUSE_199601
    UNION ALL
    SELECT * FROM TBCARDUSE_199512
    UNION ALL
    SELECT * FROM TBCARDUSE_199511
    UNION ALL
    SELECT * FROM TBCARDUSE_199510
    UNION ALL
    SELECT * FROM TBCARDUSE_199509
    UNION ALL
    SELECT * FROM TBCARDUSE_199508
    UNION ALL
    SELECT * FROM TBCARDUSE_199507
    SELECT * FROM PV_TBCARDUSE1
    WHERE USE_NO = '123456' ---+
    AND CARD_NO = '45991276182212' ---+ (UNQUE)
    AND ROWNUM = 1;
    (사례)에서 시간적으로 최근의 TABLE을 먼저 UNION ALL하여
    사용하였다. 이는 원하는 정보가 최근에 있을 확률이 높기때문에
    먼저 찾게되면 더이상 TABLE의 ACCESS를 하지 않기때문이다.
    (3) HINT의 사용
    Partition View에 Hint 사용은 보통의 Query에 대해서와 같이
    사용한다.
    (1) PARALLEL HINT
    SELECT /*+ PARALLEL(PV_TBCARDUSE,2) */
    SUM(AUTH_AMT)
    FROM PV_TBCARDUSE
    WHERE AUTH_DATE BETWEEN '19960501' AND '19960731'
    TBCARDUSE_199605,TBCARDUSE_199606,TBCARDUSE_199607
    Table을 Parallel로 처리한다.
    (2) INDEX_DESC HINT
    이는 INDEX이름이 HINT내에 들어가야 하므로 원칙적으로는
    불가능하지만 사용 될 Table이 명확하게 정의된다면 사용 할
    수도 있다.
    SELECT /*+ INDEX_DESC(a TBACRDUSE_199605_IDX1) */
    FROM PV_TBCARDUSE a
    WHERE CARD_NO = '4599243141847231'
    AND AUTH_DATE BETWEEN '19960501' AND '19960531'
    AND ROWNUM = 1

    Hello,
    Incorrect Display of Tables and Frames in Firefox when DESFORMAT=HTMLCSS (Doc ID 412272.1)
    Regards

  • DW Partitioned View not updateable

    We recently added a list enum root to a management pack that also contained Data Warehouse elements. when we imported the updated version of the MP to Service Manager the DW Load.Common job started failing.
    This Job Module does not have a date value watermark so I can not reset the watermark value.
    The MP is sealed and was not generating any errors before the recent edit to the MP I have done a compare of the pre and post xml and none of the DW elements were edited.
    Events from the Operations Manager event log on the SM DW server
     ID 33502
    ETL Module Execution failed:
     ETL process type: Load
     Batch ID: 35873
     Module name: LoadDWDataMartCITAM_AgreementHasAssetFact8
     Message: Partitioned view 'DWDataMart.dbo.CITAM_AgreementHasAssetFact8vw' is not updatable because it does not deliver all columns from its member tables.
    Event ID 33503 is a warning, it is generated 3 times before the 33502 error  
     ETL process type: Load
     Batch ID: 35873
     Module name: LoadDWDataMartCITAM_AgreementHasAssetFact8
     Message: Partitioned view 'DWDataMart.dbo.CITAM_AgreementHasAssetFact8vw' is not updatable because it does not deliver all columns from its member tables.
    corresponding errors from the trace log.
    [5]0B10.400C::02/13/2014-13:41:05.315 [Microsoft.EnterpriseManagement.Warehouse.Server]( 0000000001FEB4CA )Exception occured during PartitionedViewInsert operation: Message = Partitioned view 'DWDataMart.dbo.CITAM_AgreementHasAssetFact8vw' is not updatable
    because it does not deliver all columns from its member tables., Stacktrace =    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
       at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
       at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
       at Microsoft.SystemCenter.Warehouse.Utility.SqlBulkOperation.PartitionedViewUpdate(SqlConnection sourceConnection, String sourceQuery, String destinationTable, Dictionary`2 mapping, SqlConnection destinationConnection, Collection`1 pkColumns)
       at Microsoft.SystemCenter.Warehouse.Utility.SqlBulkOperation.PartitionedViewUpsert(String sourceConnectionString, String sourceQuery, String destinationTable, Dictionary`2 mapping, String destinationConnectionString, Collection`1 pkColumns, Int32&
    insertCount, Int32& updateCount, DomainUser sourceSecureUser, DomainUser destSecureUser, SqlResourceStore targetStore)
       at Microsoft.SystemCenter.Warehouse.Etl.ADOInterface.PartitionedViewUpsert(DomainUser sourceConnectionUser, DomainUser destinationConnectionUser)
    [5]0B10.400C::02/13/2014-13:41:05.318 [Microsoft.EnterpriseManagement.Warehouse.Etl]( 0000000003E2531C )SqlException occured while executing ETL Job module: etlMod = Microsoft.SystemCenter.Warehouse.Etl.LoadModule ModuleName = LoadDWDataMartCITAM_AgreementHasAssetFact8,
    SourceId = 1, Guid = bd3a60b2-2edb-5667-625c-7d19862dd0b7, Instance = , WarehouseModule = LoadDWDataMartCITAM_AgreementHasAssetFact8, ModuleType = Load, ExecutableType = ADOInterface, Executable.InstanceId = ADOInterface, JobName = Load.Common, TargetEntity
    = Microsoft.SystemCenter.Warehouse.Schema.BaseEntity entityName = CITAM_AgreementHasAssetFact8, entityType = Fact, entityId = 90f7120c-0a40-d4a4-8eac-a2c442f62d38, sourceId = 1, attempts = 0, Message = Partitioned view 'DWDataMart.dbo.CITAM_AgreementHasAssetFact8vw'
    is not updatable because it does not deliver all columns from its member tables., StackTrace =    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
       at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
       at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
       at Microsoft.SystemCenter.Warehouse.Utility.SqlBulkOperation.PartitionedViewUpdate(SqlConnection sourceConnection, String sourceQuery, String destinationTable, Dictionary`2 mapping, SqlConnection destinationConnection, Collection`1 pkColumns)
       at Microsoft.SystemCenter.Warehouse.Utility.SqlBulkOperation.PartitionedViewUpsert(String sourceConnectionString, String sourceQuery, String destinationTable, Dictionary`2 mapping, String destinationConnectionString, Collection`1 pkColumns, Int32&
    insertCount, Int32& updateCount, DomainUser sourceSecureUser, DomainUser destSecureUser, SqlResourceStore targetStore)
       at Microsoft.SystemCenter.Warehouse.Etl.ADOInterface.PartitionedViewUpsert(DomainUser sourceConnectionUser, DomainUser destinationConnectionUser)
       at Microsoft.SystemCenter.Warehouse.Etl.ADOInterface.Execute(IXPathNavigable config, Watermark wm, DomainUser sourceConnectionUser, DomainUser destinationConnectionUser)
       at Microsoft.SystemCenter.Warehouse.Etl.LoadModule.Execute(IXPathNavigable config, Watermark wm, DomainUser sourceConnectionUser, DomainUser destinationConnectionUser, Int32 loadBatchSize)
       at Microsoft.SystemCenter.Warehouse.Etl.LoadModule.Execute(IXPathNavigable config, Watermark wm, DomainUser sourceConnectionUser, DomainUser destinationConnectionUser)
       at Microsoft.SystemCenter.Etl.ETLModule.OnDataItem(DataItemBase dataItem, DataItemAcknowledgementCallback acknowledgedCallback, Object acknowledgedState, DataItemProcessingCompleteCallback completionCallback, Object completionState) 
     [5]0B10.400C::02/13/2014-13:41:09.522 [Microsoft.EnterpriseManagement.Warehouse.Etl]( 0000000003E2531C )Updating WorkItem for: etlWI =  WorkItemId = 13250945, processModuleId = 14757, isDirty = True, BatchId = 35873, status = Failed, RetryCount
    = 0, ErrorCount = 174, TakenTime = 02/13/2014 19:41:04, Module = ModuleName = LoadDWDataMartCITAM_AgreementHasAssetFact8, ModuleType = System, ModuleDescription = Deployment Execution Step, ProcessCategoryName = Load, ProcessName = Load.Common, DeletedBatchId=0
    [5]0B10.400C::02/13/2014-13:41:09.527 [Microsoft.EnterpriseManagement.Orchestration]( 00000000035A96C4 )Updating WorkItem for: =  WorkItemId = 13250945, processModuleId = 14757, isDirty = True, BatchId = 35873, status = Failed, RetryCount = 0, ErrorCount
    = 174, TakenTime = 02/13/2014 19:41:04, Module = ModuleName = LoadDWDataMartCITAM_AgreementHasAssetFact8, ModuleType = System, ModuleDescription = Deployment Execution Step, ProcessCategoryName = Load, ProcessName = Load.Common, DeletedBatchId=0

    Anybody found a solution?

  • Partitioned views in Standard Edition

    We have are SQL 2014 Standard edition, I have a situation where-in I plan to partition a table now since table partition is not supported in standard version I thought about Partitioned views however now I am stuck where I cant make the view writable because
    of the identity column in the base table.
    Do I have any other option in this case ?
    Let me know your thoughts
    Regards
    Vishal
    VG

    Identity columns are problematic for a partitioned view. If any of the tables include an identity column, you can delete but not insert or update via the view.  You could instead use a sequence to generate the surrogate key values, but that may require
    significant application changes.
    The real question is why you want to partition.  There are specialized use cases where partitioning may improve performance (e.g. parallel scans) but you will generally get more benefit from index and query tuning.  Partitioning (view
    or table) can actually degrade performance depending on the queries and workload.  That being said, partitioning always improves manageability.
    Be aware that there is additional overhead of partitioned views compared to partitioned tables.  Each table within the view may be indexed differently so there is considerable more work for the optimizer to do to generate an efficient plan. 
    This increases compilation time and can result in suboptimal plans, particularly if the view contains many tables.  If your table is so large that partitioning is compelling, you might start making the business case for Enterprise Edition in order
    to meet performance and availability SLAs.
    I think the Database Engine forum is a better fit for this question so I'll move this thread there.
    Dan Guzman, SQL Server MVP, http://www.dbdelta.com

  • SQL Server Distributed Partitioning Views how to add a new node online

    We are using distributed partitioning views in SQL Server 2012 Enterprise Edition for scaling out our data across more than one servers. Now we faced to question how to add a new node (server) into the scale outed db servers system without sending the servers
    down, so our users will be able to use them during the process as well.
    For example we have 4 servers with scaled out data. When we add the new empty server, the CHECKINGs for the partitioning columns should be reorganized. But during the process the partitioning views are not working.
    The High Availability, Always On or Failover Cluster approaches seem are not resolve the problems.
    So my question is how to add new node online?
    KH

    Thank you Erland for the reply.
    Yes, it's sounds as possible solution but has some not resolvable nuance in it. Let's say we copied some data from Node5 to new added Node6. Let's assume in Node5 we had data in Table1 with partitioning column's values 100,101,102,103,104,105,106.  Now
    we want to copy part of the rows with partitioning column's values 103,104,105,106 from Node5.Table1 into Node6.Table1. With this Node5 will contain less data and will work more quickly (less IO, less CPU usage etc), and the rest data will be contained on
    Node6. But because of Node5 is already in use, the Node5.Table1 contains CHECK CONSTRAINT = ParttionColumn should be from 100 up to 106. This is check for Node5. The Distributed Partitioning Views are already using the CHECKs to identify what server should
    be used to get data from.
    Now when we copied part of the Node5.Table1 rows to Node6.Table1 the views are still using the 103-106 rows from Node5.Table1 because the CHECK points there. Then we include the newest Node6.Table1 in the distributed partitioning views. OK, but we should
    set some CHECK on new Node6.Table1 which will be used by views. We can't set intersecting checking like Node5 has CHECK 100-106 and Node6 has CHECK 103-106. We also can't edit Node5 check and set it 100-102 untill the data will be removed in it. But this means
    that the data will not be available during the execution. 
    So, any ideas ?
    KH

  • ORA-1779 when updating a view

    Hi and thanks in advance !
    i am facing a critical situation.
    i have two schema & both are same!
    the problem which i am facing is during updating a view of one i am facing above error while the same DML is issuing againt that view in other schema and that works fine.
    what's the reason..
    The major difference between two schema's is i hav different live and test database i migrate my access database to Oracle test database # 1.here i created a new user name deals . ok
    i hav done same migration in my another database but a little difference here user deals is already available here and tables and views are also available i drop all the object but forget to purge recyclebin. now whenever i try to issue DML at this schema i am facing above error while the same tables same data and same view is available in above databae where my update statement executed properly. one more thing i like to add here i hav some unwanted trigger 'BIN$##$$%##$# bla bla bla' on different table. i haven't created that .
    here is the view for your kind perusal
    CREATE OR REPLACE VIEW QRYREUTER AS
    SELECT FXdeals.deal_no,
    cparty.name,
    cparty.city,
    FXdeals.brokbill,
    FXdeals.deal_date,
    FXdeals.mode_id
    FROM FXDeals
    JOIN cparty
    ON FXdeals.cpcode = cparty.cpcode
    WHERE ( ( (FXdeals.mode_id) = 3 ) )
    Message was edited by:
    Fiz Dosani

    but i have sample scenario in other schema which replica of this schema so why i haven't got this error there
    one more interesting thing when i query select * from user_updateable_columns where table name ='ABC' in Schema # 1 it return i can modify some columns.
    but when issue the data dictionary view in schema # 2, where i was facing ORA-1779 , select * from user_updateable_columns where table name ='ABC' in Schema # 2 it return i can not modify any columns.
    Tables name are same in both schema.
    Data same in both schema.
    Constraint Same in both schema.
    Indexes same in both schema.
    why facing error in one schema not in other.
    one more interesting thing, i had faced questionable object error when importing DMP into schema # 2.

  • Update maintenance view data by FM .

    Hi friends,
             I want to update Maintenance view data  not by using sm30,sm34,transactions . i want to update by FM . i will pass the data and view name  so that it should update the data in views( and corresponding tables ) .
    and  we need these changes should be stored in change request also .
    Regards,
    Shiva.

    you can use FM
    VIEW_MAINTENANCE_NO_DIALOG
    with action parameter = 'SAVE'
    just do a where used list of this FM to check how this can be used
    Regards
    Raja

  • Creating a role to update a view

    Hi.
    Oracle 10.2.04. Linux 4.
    I have been reading about updating views. The Oracle documentation http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views001.htm#i1006887 states that:
    The owner of the view (whether it is you or another user) must have been explicitly granted privileges to access all objects referenced in the view definition. The owner cannot have obtained these privileges through roles. Also, the functionality of the view depends on the privileges of the view owner. For example, if the owner of the view has only the INSERT privilege for Scott's emp table, then the view can be used only to insert new rows into the emp table, not to SELECT, UPDATE, or DELETE rows.
    This is helpful, but doesn't resolve my issue.
    A role has been created to allow access to a view called SALES_RESULTS:
    create role update NOT IDENTIFIED;
    GRANT INSERT, SELECT, UPDATE ON SALES_RESULTS TO update;
    GRANT update to user;
    When user tries to update the view however, an error is returned. (Sorry, I dont know the error just yet!!)
    In essence, my question is: in order for the updates to work, does the user 'user' need explicitly granted priviliges on the underlying objects, as stated in the Oracle doc extract above - which was discussing the owner of the view?
    Thanks.
    DA

    You have an actual example that shows it does not work. Also, it is stated in the documentation.
    What else do you need?
    Kind regards
    Uwe
    http://uhesse.wordpress.com

  • Partition view on 10g and 11g

    Hi All,
    I am on 10.2 Standard edition and 11.1 Standard edition (2 databases in the application, one on 10g, another on 11g).
    Being on standard edition, cannot use many common features e.g. partitioning, bitmap indexes etc.
    I use to think that, partitioned view are no more supported by Oracle. But I can see that it works. I created 3 tables TEMP1, TEMP2 and TEMP3, all with exact same structure (columns and indices). Then created a view TEMP_VIEW, which is like
    select col1, col2, col3 .... from temp1
    union all
    select col1, col2, col3 .... from temp2
    union all
    select col1, col2, col3 .... from temp3Here are the query execution and plans
    /* ----------------- 10g execution plan ----------------------- */
    SQL> select * from temp_view where object_id=2620 and branch_cd = 'XYZ';
    OWNER                          OBJECT_NAME                    SUBOBJECT_NAME                  OBJECT_ID DATA_OBJECT_ID
    OBJECT_TYPE         CREATED   LAST_DDL_ TIMESTAMP           STATUS  T G S BRANC
    SYS                            LOADER_TRIGGER_INFO                                                 2620
    VIEW                18-FEB-09 16-APR-09 2009-02-18:10:07:57 VALID   N N N XYZ
    Elapsed: 00:00:00.29
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=132)
       1    0   VIEW OF 'TEMP_VIEW' (VIEW) (Cost=2 Card=1 Bytes=132)
       2    1     UNION-ALL (PARTITION)
       3    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP1' (TABLE) (Cost=2 Card=1 Bytes=132)
       4    3         INDEX (UNIQUE SCAN) OF 'TEMP1_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
       5    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP2' (TABLE) (Cost=2 Card=1 Bytes=132)
       6    5         INDEX (UNIQUE SCAN) OF 'TEMP2_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
       7    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP3' (TABLE) (Cost=2 Card=1 Bytes=132)
       8    7         INDEX (UNIQUE SCAN) OF 'TEMP3_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
    /* ----------------- 11g execution plan ----------------------- */
    SQL> select * from temp_view where object_id=2620 and branch_cd = 'XYZ';
    OWNER                          OBJECT_NAME                    SUBOBJECT_NAME                  OBJECT_ID DATA_OBJECT_ID
    OBJECT_TYPE         CREATED   LAST_DDL_ TIMESTAMP           STATUS  T G S BRANC
    PUBLIC                         GV$XML_AUDIT_TRAIL                                                  2620
    SYNONYM             16-NOV-09 16-NOV-09 2009-11-16:16:36:08 VALID   N N N XYZ
    Elapsed: 00:00:00.03
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=3 Bytes=396)
       1    0   VIEW OF 'TEMP_VIEW' (VIEW) (Cost=6 Card=3 Bytes=396)
       2    1     UNION-ALL
       3    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP1' (TABLE) (Cost=2 Card=1 Bytes=102)
       4    3         INDEX (UNIQUE SCAN) OF 'TEMP1_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
       5    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP2' (TABLE) (Cost=2 Card=1 Bytes=102)
       6    5         INDEX (UNIQUE SCAN) OF 'TEMP2_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
       7    2       TABLE ACCESS (BY INDEX ROWID) OF 'TEMP3' (TABLE) (Cost=2 Card=1 Bytes=102)
       8    7         INDEX (UNIQUE SCAN) OF 'TEMP3_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)Questions
    1) I am expecting same behaviour on Oracle enterprise edition, will that be the case ?
    2) On 10g, execution plan shows "UNION-ALL (PARTITION)", but on 11g it says, "UNION-ALL". What does that imply?
    3) Which Oracle parameter can affect this behaviour? the old partition_view_enable parameter does not exist
    4) If I go ahead and use this partitioned view, in which cases this can cause problems? At this point, it looks all good if I access the view using indexed columns (of the tables and all tables involved have exactly same indexes).
    Thanks in advance

    Billy Verreynne is an expert in this area and has been introducing people for years to 'partition views' and you can find many of his previous posts about how and when to use them (including example code) right here in these forums (most of them will be in the SQL and PL/SQL forum).
    This feature has been around since Oracle 7 and the 7.3 document that details the info is still at
    http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm
    Here is just one of his many other threads with more example code using five tables.
    Table name in from clause

  • Issue with updating partitioned table

    Hi,
    Anyone seen this bug with updating partitioned tables.
    Its very esoteric - its occurs when we update a partitioned table using a join to a temp table (not non-temp table) when the join has multiple joins and you're updating the partitoned column that isn't the first column in the primary key and the table contains a bit field. We've tried changing just one of these features and the bug disappears.
    We've tested this on 15.5 and 15.7 SP122 and the error occurs in both of them.
    Here's the test case - it does the same operation of a partitioned table and a non-partitioned table, but the partitioned table shows and error of "Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'".
    I'd be interested if anyone has seen this and has a version of Sybase without the issue.
    Unfortunately when it happens on a replicated table - it takes down rep server.
    CREATE TABLE #table1
        (   PK          char(8) null,
            FileDate        date,
            changed         bit
    CREATE TABLE partitioned  (
      PK         char(8) NOT NULL,
      ValidFrom     date DEFAULT current_date() NOT NULL,
      ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    LOCK DATAROWS
      PARTITION BY RANGE (ValidTo)
      ( p2014 VALUES <= ('20141231') ON [default],
      p2015 VALUES <= ('20151231') ON [default],
      pMAX VALUES <= (MAX) ON [default]
    CREATE UNIQUE CLUSTERED INDEX pk
      ON partitioned(PK, ValidFrom, ValidTo)
      LOCAL INDEX
    CREATE TABLE unpartitioned  (
      PK         char(8) NOT NULL,
      ValidFrom     date DEFAULT current_date() NOT NULL,
      ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    LOCK DATAROWS
    CREATE UNIQUE CLUSTERED INDEX pk
      ON unpartitioned(PK, ValidFrom, ValidTo)
    insert partitioned
    select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    insert unpartitioned
    select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    insert #table1
    select "ET00jPzh", "Jan 15 2015", 1
    union all
    select "ET00jPzh", "Jan 15 2015", 1
    go
    update partitioned
    set    ValidTo = dateadd(dd,-1,FileDate)
    from   #table1 t
    inner  join partitioned p on (p.PK = t.PK)
    where  p.ValidTo = '99991231'
    and    t.changed = 1
    go
    update unpartitioned
    set    ValidTo = dateadd(dd,-1,FileDate)
    from   #table1 t
    inner  join unpartitioned u on (u.PK = t.PK)
    where  u.ValidTo = '99991231'
    and    t.changed = 1
    go
    drop table #table1
    go
    drop table partitioned
    drop table unpartitioned
    go

    wrt to replication - it is a bit unclear as not enough information has been stated to point out what happened.  I also am not sure that your DBA's are accurately telling you what happened - and may have made the problem worse by not knowing themselves what to do - e.g. 'losing' the log points to fact that someone doesn't know what they should.   You can *always* disable the replication secondary truncation point and resync a standby system, so claims about 'losing' the log are a bit strange to be making. 
    wrt to ASE versions, I suspect if there are any differences, it may have to do with endian-ness and not the version of ASE itself.   There may be other factors.....but I would suggest the best thing would be to open a separate message/case on it.
    Adaptive Server Enterprise/15.7/EBF 23010 SMP SP130 /P/X64/Windows Server/ase157sp13x/3819/64-bit/OPT/Fri Aug 22 22:28:21 2014:
    -- testing with tinyint
    1> use demo_db
    1>
    2> CREATE TABLE #table1
    3>     (   PK          char(8) null,
    4>         FileDate        date,
    5> --        changed         bit
    6>  changed tinyint
    7>     )
    8>
    9> CREATE TABLE partitioned  (
    10>   PK         char(8) NOT NULL,
    11>   ValidFrom     date DEFAULT current_date() NOT NULL,
    12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    13>   )
    14>
    15> LOCK DATAROWS
    16>   PARTITION BY RANGE (ValidTo)
    17>   ( p2014 VALUES <= ('20141231') ON [default],
    18>   p2015 VALUES <= ('20151231') ON [default],
    19>   pMAX VALUES <= (MAX) ON [default]
    20>         )
    21>
    22> CREATE UNIQUE CLUSTERED INDEX pk
    23>   ON partitioned(PK, ValidFrom, ValidTo)
    24>   LOCAL INDEX
    25>
    26> CREATE TABLE unpartitioned  (
    27>   PK         char(8) NOT NULL,
    28>   ValidFrom     date DEFAULT current_date() NOT NULL,
    29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    30>   )
    31> LOCK DATAROWS
    32>
    33> CREATE UNIQUE CLUSTERED INDEX pk
    34>   ON unpartitioned(PK, ValidFrom, ValidTo)
    35>
    36> insert partitioned
    37> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    38>
    39> insert unpartitioned
    40> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    41>
    42> insert #table1
    43> select "ET00jPzh", "Jan 15 2015", 1
    44> union all
    45> select "ET00jPzh", "Jan 15 2015", 1
    (1 row affected)
    (1 row affected)
    (2 rows affected)
    1>
    2> update partitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join partitioned p on (p.PK = t.PK)
    6> where  p.ValidTo = '99991231'
    7> and    t.changed = 1
    Msg 2601, Level 14, State 6:
    Server 'PHILLY_ASE', Line 2:
    Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
    Command has been aborted.
    (0 rows affected)
    1>
    2> update unpartitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join unpartitioned u on (u.PK = t.PK)
    6> where  u.ValidTo = '99991231'
    7> and    t.changed = 1
    (1 row affected)
    1>
    2> drop table #table1
    1>
    2> drop table partitioned
    3> drop table unpartitioned
    -- duplicating with 'int'
    1> use demo_db
    1>
    2> CREATE TABLE #table1
    3>     (   PK          char(8) null,
    4>         FileDate        date,
    5> --        changed         bit
    6>  changed int
    7>     )
    8>
    9> CREATE TABLE partitioned  (
    10>   PK         char(8) NOT NULL,
    11>   ValidFrom     date DEFAULT current_date() NOT NULL,
    12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
    13>   )
    14>
    15> LOCK DATAROWS
    16>   PARTITION BY RANGE (ValidTo)
    17>   ( p2014 VALUES <= ('20141231') ON [default],
    18>   p2015 VALUES <= ('20151231') ON [default],
    19>   pMAX VALUES <= (MAX) ON [default]
    20>         )
    21>
    22> CREATE UNIQUE CLUSTERED INDEX pk
    23>   ON partitioned(PK, ValidFrom, ValidTo)
    24>   LOCAL INDEX
    25>
    26> CREATE TABLE unpartitioned  (
    27>   PK         char(8) NOT NULL,
    28>   ValidFrom     date DEFAULT current_date() NOT NULL,
    29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
    30>   )
    31> LOCK DATAROWS
    32>
    33> CREATE UNIQUE CLUSTERED INDEX pk
    34>   ON unpartitioned(PK, ValidFrom, ValidTo)
    35>
    36> insert partitioned
    37> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    38>
    39> insert unpartitioned
    40> select "ET00jPzh", "Jan  7 2015", "Dec 31 9999"
    41>
    42> insert #table1
    43> select "ET00jPzh", "Jan 15 2015", 1
    44> union all
    45> select "ET00jPzh", "Jan 15 2015", 1
    (1 row affected)
    (1 row affected)
    (2 rows affected)
    1>
    2> update partitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join partitioned p on (p.PK = t.PK)
    6> where  p.ValidTo = '99991231'
    7> and    t.changed = 1
    Msg 2601, Level 14, State 6:
    Server 'PHILLY_ASE', Line 2:
    Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
    Command has been aborted.
    (0 rows affected)
    1>
    2> update unpartitioned
    3> set    ValidTo = dateadd(dd,-1,FileDate)
    4> from   #table1 t
    5> inner  join unpartitioned u on (u.PK = t.PK)
    6> where  u.ValidTo = '99991231'
    7> and    t.changed = 1
    (1 row affected)
    1>
    2> drop table #table1
    1>
    2> drop table partitioned
    3> drop table unpartitioned

  • Updatable Materialized View and Master Table on same database

    Hi all,
    My first question - Is it possible to have an Updatable Materialized View and the associated Master Table located on the same database?
    This is the requirement scenario:
    One unique database D exists.
    A is a batch table. Only inserts are allowed on Table A.
    M is an updatable materialized view on Table A (Master). Only updates are allowed on M (no insert or delete).
    Requirement is to push updates/changes from M to A periodically and then get the new inserted records from A into M via a refresh.
    Is this possible? What other approaches are applicable here?

    John,
    My question is related to the implementation and setup of the environment as explained in the above example. How can I achieve this considering that I have created an updatable m-view?
    If possible, how do I push changes made to an updatable m-view back to it's master table when/before I execute DBMS_MVIEW.REFRESH on the m-view? What is the procedure to do this if both table and mview exist on the same database? Do I need to create master groups, materialized view refresh groups, etc.?
    One more thing.. Is there a way to retain changes to the m-view during refresh? In this case, only newly inserted/updated records in the associated table would get inserted into m-view. Whereas changes made to m-view records would stay as-is.
    Hope my question is directed well. Thanks for your help.
    - Ankit

  • Scheduling updatable materialized view

    Hi everybody,
    As you may know I have a solution in which I have 5 sites .One master site with 4 updatable materialized view sites.
    I want to know that is it correct if I dont set up schedule push to run periodically and set it up to do continuous push ?
    I want in at least 2 minutes all sites become update and I have to mention that at first I tried multimaster but our client doesn't want that because they want if one special site becomes unavailable they others can not transfer data to eachother.
    I appreciate your help in advance.

    Your requirements are a bit unclear...
    1) In general, if you are looking to have sites updated within a minute or two of the original transaction being committed, you are better off looking at something like Streams rather than using materialized views.
    2) Architecturally, when you set up multi-master replication (which it sounds like you are attempting to do here), you need to choose between synchronous and asynchronous replication. Synchronous replication means that a transaction cannot commit until it has been pushed to all the other nodes, which is great for latency but horrible for performance, scalability, and availability. Very, very few people really want synchronous replication. That leaves asynchronous replication, which would require you to schedule jobs to replicate changes. Some folks who think they want asnychronous replication really want another technology entirely (i.e. DataGuard, RAC, etc).
    3) Are you sure about the requirement "they want if one special site becomes unavailable they others can not transfer data to each other"? That says that if one site fails, they want all transactions everywhere to fail. That pretty much defeats the purpose of setting up multi-master replication. If the system is only available as long as every node is available, and you're going to incur the overhead of synchronous replication on every change, you would be far better served consolidating everything into a single data center and potentially using RAC to create a multi-node cluster to spread the work among nodes. There would be very little benefit to offset the complexity of configuring and maintaining a multi-master replication environment if you didn't want the nodes to be able to continue in the event that one of them failed.
    Justin

  • Updatable materialized view- error with CREATE_SNAPSHOT_REPGROUP

    I'm trying to create an updatable materialized view from the replication administrators account (REPADMIN). I use the assistant and in the third step (after creating the replication group and the materialized view), when the materialized view is going to be added to the group, I got this error:
    ERROR in line 1:
    ORA-01403: No data found
    ORA-06512: in "SYS.DBMS_REPCAT_SNA_UTL", line 5927
    ORA-06512: in "SYS.DBMS_REPCAT_SNA", line 82
    ORA-06512: in "SYS.DBMS_REPCAT", line 1332
    ORA-06512: in "SYS.DBMS_REPCAT", line 1307
    ORA-06512: in line 2
    I have also tried to use the command file that the assistant generates (I add below), and the error is triggered within the CREATE_SNAPSHOT_REPOBJECT procedure.
    Has anybody any idea to resolve the problem?
    Thanks in advance
    BEGIN
    DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP(
    gname => '"MYGROUP"',
    master => 'DB.DOMAIN.COM',
    propagation_mode => 'ASYNCHRONOUS');
    END;
    CREATE SNAPSHOT "MYUSER"."MYTABLE"
    REFRESH COMPLETE WITH ROWID
    FOR UPDATE
    AS SELECT "COD", "NAME" FROM
    "MYUSER"."MYTABLE"@DB.DOMAIN.COM c
    BEGIN
    DBMS_REFRESH.ADD(
    name => '"MYUSER"."REF3"',
    list => '"MYUSER"."MYTABLE"',
    lax => TRUE);
    END;
    BEGIN
    DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT(
    gname => '"MYGROUP"',
    sname => '"MYUSER"',
    oname => '"MYTABLE"',
    type => 'SNAPSHOT',
    min_communication => FALSE);
    END;

    Hello,
    These days I have had some problems with my forum-account and I haven't been able to connect and reply.
    Regarding to your doubt, the name of refresh group was correct, and as I see, the problem can't be related to the refresh group.
    While the problem with my account was resolved, I created two new databases (*) and the problem within the materialized view process is disappeared. I suppose that my first original databases were degraded, but I don't know where.
    (*) of course, I could do that because I use Oracle in an academy institution, not for production, thank God
    Anyway, for now I will give up here. Thanks for your help.
    Regards,

  • (V7.3) PARTITION VIEWS IN ORACLE7 RELEASE 7.3

    제품 : ORACLE SERVER
    작성날짜 : 2002-05-17
    PURPOSE
    Introduction
    Partition views are a new feature in Release 7.3 design to provide
    better support for very large tables that are commonly found in data
    warehousing environments.
    The partition view feature offers two primary benefits:
    - improved managability and availability of large tables
    - improved performance for table scans on certain queries of
    these large tables
    Explanation & Example
    What is a partion view?
    An example partition view is:
    create view sales as
    select * from jan_sales
    union all
    select * from feb_sales
    union all
    select * from dec_sales
    Each of the base tables (the monthly sales tables) must be identical
    in terms of column names, column datatypes, and indexes. These tables
    must also have a CHECK constraint on its partitioning column (thus,
    the jan_sales table must have a check constraint on the date column
    which constrains the date to fall between Jan 1 and Jan 31).
    All of these base tables, indexes, constraints as well as the
    UNION-ALL view definition are be created by the DBA.
    Managability and availability benefits
    A partition view greatly simplifies the administration of very large
    tables.
    Consider the example of of a data warehousing containing a large
    'sales' table. Once per month, the DBA loads all of new sales data
    into this table. Thus, the DBA would need to drop all of the indexes
    on the sales, load the new data, and rebuild the indexes. Since the
    sales table is very large, this could be a lengthy operation.
    Morever, the sales table is (for most practical DSS application) is
    not available while these load and index operations are occuring.
    Using the partition view feature, the DBA could load the new month's
    data into a separate partition and build indexes on this new partition
    without impacting the original partition view. Then, after the new
    partition is entirely built and indexed, the DBA could recreate the
    UNION-ALL view to include the new partition. The sales partition view
    is unavailable for a very short length of time ... only while the
    UNION-ALL view is being built. Moreover, because the indexes are much
    smaller, the length of time to load and index a new month's worth of
    data is dramatically decreased.
    Performance benefits of partition views
    Any UNION-ALL view (even in earlier releases of Oracle7) can reap the
    aforementioned managability benefits; however, unless the UNION-ALL
    view offers reasonable query performance, the managability benefits
    are useless.
    The enhancement in Release 7.3 is to insure that the query performance
    on UNION-ALL views will at least equivalent to (and, in many cases,
    much better than) single-table access. Note that these performance
    enhancements are only effective when all of the partitions have the
    appropriate CHECK constraints and when all of the partitions have
    identical column definitions and indexes.
    There are two basic performance enhancements for partition views:
    partition elimination
    parallel execution of UNION-ALL views
    Certain queries may not require data from all of the partitions of a
    view partition. For example, consider the following query:
    select sum(revenues) from sales
    where sales_date between '15-JAN-96' and '15-FEB-96';
    With 7.3's new support for partition views, Oracle will evaluate the
    above query using only the January partition and the February
    partition; the remaining ten partitions will not be accessed. This
    feature is commonly called 'partition elimination'.
    Partition elimination is only effective when querying based on the
    partitioning column; in this example, the partitioning column is the
    sales_date column. But the performance savings can be significant. In
    the previous example, the partition view feature results in ten of the
    twelve partitions being eliminated from query processing. This could
    represent six-fold performance gain.
    An additional enhancement in 7.3 is the parallel execution of
    UNION-ALL views. All queries on UNION-ALL views can be executed in
    parallel (when using the Parallel Query Option). It is very
    important to note that the partitioning scheme is absolutely
    independent of the degree of parallelism (this starkly contrasts with
    many of our competitior's parallel query architecture, in which the
    physical data partitioning determines the degree of parallelism).
    Oracle will dynamically distribute the data of a UNION ALL view across
    all parallel query processes, and partition elimintation will not
    impact the degree of parallelism.
    Limitations of Partition Views
    Partition views do not support DML operations. For this reason,
    partition views are most appropriate for read-only applications (such
    as data warehouses).
    Conclusion
    Partition views can be very effective for handling very large tables
    in data warehousing environments. The managability of these large
    tables is vastly improved, with significant performance improvements
    for many queries.
    Reference Ducumment
    ---------------------

    The installer might not be year 2000 compliant. Download a newer version or set your system date back into 1999 ;-)

  • Partitioned views in SQL 2014 have incorrect execution plans

    I've been using partitioned views in the past
    and used the check constraint in the source tables to make sure the only the table with the condition in the where clause on the view was used. In SQL Server 2012 this was working just fine (I had to do some tricks to suppress parameter sniffing, but it was
    working correct after doing that). Now I've been installing SQL Server 2014 Developer and used exactly the same logic and in the actual query plan it is still using the other tables. I've tried the following things to avoid this:
    - OPTION (RECOMPILE)
    - Using dynamic SQL to pass the parameter values as a static string.
    - Set the lazy schema validation option to true on the linked servers
    To explain wat I'm doing is this:
    1. I have 3 servers with the same source tables, the only difference in the tables is one column with the server name.
    2. I've created a CHECK CONSTRAINT on the server name column on each server.
    3. On one of the three server (in my case server 3) I've setup linked server connections to Server 1 and 2.
    4. On Server 3 I've created a partioned view that is build up like this:
    SELECT * FROM [server1].[database].[dbo].[table]
    UNION ALL SELECT * FROM [server2].[database].[dbo].[table]
    UNION ALL SELECT * FROM [server3].[database].[dbo].[table]
    5. To query the partioned view I use a query like this:
    SELECT *
    FROM [database].[dbo].[partioned_view_name]
    WHERE [server_name] = 'Server2'
    Now when I look at the execution plan on the 2014 environment it is still using all the servers instead of just Server2 like it should be. The strange thing is that SQL 2008 and 2012 are working just fine but 2014 seems not to use the correct plan. Maybe I
    forgot something, or something is changed in 2014 and a new approach is needed but I'm a little stuck here. 
    Did someone experience the same thing and if so, how did you fix this? 

    Hi Jos,
    Glad to hear that you have found a solution for your problem. Thank you for your sharing which will help other forum members who have the similar issue.
    Regards,
    Charlie Liao
    TechNet Community Support

Maybe you are looking for