Partition based on join in data warehouse env.

Hi,
I am working on DW environment and am quite new to it.
The scenario is like there are 2 fact tables and one dimension table.
Now I need to partition both the fact tables based on the dates in Dim table. My problem is there is no date mentioned in fact table other then Surogate keys in fact tables.
Is it possible to partition the table by using join condition between fact table and Dim table and if yes how?
The structure of tables are as follows.
Please help!
Daily sales fact table
planned shipment date sk     NUMBER     PK1, FK1
source system identifier     VARCHAR2(50)     PK2
sales type indicators sk     NUMBER     PK3, FK3
ship-to-customer sk     NUMBER     PK4, FK4
product sk     NUMBER     PK5, FK5
ship-from-location sk     NUMBER     PK6, FK6
quantity in primary units     NUMBER(14,3)     
quantity in 9LE     NUMBER(14,3)     
Daily Sales Order Fact
sales invoiced date sk     NUMBER     PK1, FK1
source system identifier     VARCHAR2(50)     PK2
sales type indicators sk     NUMBER     PK3, FK3
ship-to-customer sk     NUMBER     PK4, FK4
product sk     NUMBER     PK5, FK5
ship-from-location sk     NUMBER     PK6, FK6
quantity in primary units     NUMBER(14,3)     
quantity in 9LE     NUMBER(14,3)     
Sales order month Dim
sales order month sk     NUMBER     PK1
sales order month full name     VARCHAR2(50)     
sales order month number     NUMBER(2)     
sales order month calendar year     NUMBER(4)     
sales order month financial year     NUMBER(4)     
sales order month start date     DATE     AK1
sales order month end date     DATE     
sales order month end date sk     NUMBER     
days in sales order month     NUMBER(2)     
event number     NUMBER(12)     
last update date     DATE     
Thanks in advance.

If you take care that the synthetic key values for you date are assigned in ascending order with the date value then you can range equi-partition by range on both of them without too much trouble.
Personally I don't use synthetic values as PK's on dates, partly for this very reason.

Similar Messages

  • Analyze command in a Data warehouse env

    We are doing data loads daily on our Data warehouse. On certain target tables, we have change data capture enabled. As part of loading the table ( 4 million rows total) , we remove data for a certain time period ( say a month = 50,000+ rows) and loading that again from the source. We are also doing a full table analyze part of this load and is taking a long time.
    Question is : Do we need to do the analyze command every day ? Is there a big change we would see if we run the analyze once a week ?
    Thanks.

    Hi srwijese,
    My DW actually has 12TBs and after each dataload we do stats collection from our tables, BUT, we have partitioned tables in most of cases, so we just collect it at partition level using dbms_stat package. I don't know if your enviroment is partitioned or not, if yes, do a stats collection just for partition loaded.
    P.S: If you wish add [email protected] (MSN) to share experiences.
    Jonathan Ferreira
    http://oracle4dbas.blogspot.com

  • Alter table partition based on date and status

    Hi!
    I have a strange scenario where in 100,000 to 500,000 records are created every day and records are to be maintained for 3 yrs. So to manage this table we have it partitioned based on date (so every day one new partition is created). And any partition older than 3 years are to be purged. But the catch is - the table has a 'Creation_date' and 'Close_date' parameter and as per my company's rule, I can only purge the 3 yr old data based on the 'Closed_date'. Basically we end up getting some entries with 'Close_date' that don't fall in the 3+ yr category and hence we just cannot purge the whole partition and reclaim the space.
    What would be the ideal way to partition this table to make easy maintenance!?
    eg -
    Table_1: Partition_03152006
    Col-1 Creation-date Col-2 Close-date
    AAAA 03/15/2006 BBBB 03/16/2006 I can drop this entry+
    XXXX 03/15/2006 YYYY 05/20/2006 I cannot drop this entry+
    So, I am left with non-empty partitions which I cannot purge completely. Right now, I am moving these remaining entries to another partition and purging them when they complete the 3+yr time period.
    Hope I could put in my query properly.
    NOTE: RDBMS - ORACLE 10.2.0.4 on Solaris/SPARC 64Bit
    Thanks in advance,
    Arindam
    Edited by: AB007 on Jun 19, 2009 1:15 PM

    Hi! Below is the table description and the first 5 entries of the table.
    Hi,
    Thanks for your help. Below is the table structure with the index associated with it -
    CREATE TABLE "T3TKTHEADER"
    ( "TKTNUM" VARCHAR2(13) NOT NULL ENABLE,
    "ALTTKTNUM" VARCHAR2(20),
    "CREATEDTTM" DATE,
    "CREATEUSERID" NUMBER,
    "CREATEWKGRPID" NUMBER,
    "MASTERTKTNUM" VARCHAR2(13),
    "CUSID" VARCHAR2(15),
    "CUSNAME" VARCHAR2(80),
    "CUSCNCTNAME" VARCHAR2(80),
    "CUSCNCTPHN" VARCHAR2(22),
    "ALTCUSCNCTNAME" VARCHAR2(80),
    "ALTCUSCNCTPHN" VARCHAR2(22),
    "PRTY" VARCHAR2(1),
    "SVRITY" VARCHAR2(10),
    "CURACTSEQNUM" NUMBER(*,0),
    "LASTSTASTSCHANGETM" DATE,
    "ACKNOWLEDGEFLAG" VARCHAR2(1),
    "TMGRP" NUMBER,
    "TOPGRP" NUMBER,
    "TMUSER" NUMBER,
    "TOPUSER" NUMBER,
    "RECENTTKTSCOUNT" NUMBER,
    "PRINEID" VARCHAR2(53),
    "PRINEIDSVCTYPE" VARCHAR2(128),
    "PRINEIDDETDTTM" DATE,
    "PRINEIDLOCACITY" VARCHAR2(3),
    "PRINEIDLOCASTATE" VARCHAR2(21),
    "PRINEIDLOCZCITY" VARCHAR2(3),
    "PRINEIDLOCZSTATE" VARCHAR2(21),
    "TKTTYPE" VARCHAR2(10),
    "DOMAIN" VARCHAR2(10),
    "PRODTYPE" VARCHAR2(10),
    "SYMCODE" VARCHAR2(10),
    "SYMCODEDESC" VARCHAR2(50),
    "RPTSRC" VARCHAR2(10),
    "TOTALTKTTM" NUMBER,
    "SHELLTKTTM" NUMBER(*,0),
    "OTGCLOCKON" VARCHAR2(1),
    "OTGCLOCKSEQ" VARCHAR2(5),
    "OTGTM" NUMBER,
    "ORIGNEID" VARCHAR2(80),
    "NADCODE" VARCHAR2(30),
    "NADDTTM" DATE,
    "NADCODEDESC" VARCHAR2(50),
    "OTGCAUSE" VARCHAR2(50),
    "RESLCODE" VARCHAR2(10),
    "PLATFORM" VARCHAR2(30),
    "CATEQUIP" VARCHAR2(30),
    "RESOLVEDDT" DATE,
    "CLOSEDDT" DATE,
    "PROBSUMMARY" VARCHAR2(500),
    "TOPGRPESCSTS" VARCHAR2(1),
    "TOPGRPESCLEV" VARCHAR2(2),
    "TOPGRPLASTESCTM" DATE,
    "TMGRPESCSTS" VARCHAR2(1),
    "TMGRPESCLEV" VARCHAR2(2),
    "TMGRPLASTESCTM" DATE,
    "FAIFLAG" VARCHAR2(1),
    "MSIFLAG" VARCHAR2(1),
    "CHRONICFLAG" VARCHAR2(1),
    "SLAMTTR" NUMBER,
    "TSPCODE" VARCHAR2(13),
    "DEFERREDSTARTTM" DATE,
    "TOTALDEFERREDDUR" NUMBER,
    "CURSTA" VARCHAR2(10),
    "CURSTS" VARCHAR2(10),
    "STSCOMMENT" VARCHAR2(100),
    "ACTIVEINTREFERRALS" NUMBER(*,0),
    "ACTIVEEXTREFERRALS" NUMBER(*,0),
    "NUMOFXREFS" NUMBER(*,0),
    "LASTUPDDTTM" DATE,
    "LASTUPDUSERID" NUMBER,
    "CREATEUSERID_NAME" VARCHAR2(21),
    "CREATEWKGRPID_NAME" VARCHAR2(21),
    "TMGRP_NAME" VARCHAR2(21),
    "TOPGRP_NAME" VARCHAR2(21),
    "TMUSER_NAME" VARCHAR2(21),
    "TOPUSER_NAME" VARCHAR2(21),
    "RESLCODEDESC" VARCHAR2(50),
    "RDB_INSERT_DATE" DATE,
    "CUSCNCTHOMEPHN" VARCHAR2(22),
    "CUSCNCTCELLPHN" VARCHAR2(21),
    "CUSCNCTFAXNUM" VARCHAR2(22),
    "CUSCNCTEMAIL" VARCHAR2(47),
    "ALTCUSCNCTHOMEPHN" VARCHAR2(22),
    "ALTCUSCNCTCELLPHN" VARCHAR2(21),
    "ALTCUSCNCTFAXNUM" VARCHAR2(22),
    "ALTCUSCNCTEMAIL" VARCHAR2(47),
    "CUSCNCTALTPHN" VARCHAR2(22),
    "ALTCUSCNCTALTPHN" VARCHAR2(22),
    "CREATEUSERNAME" VARCHAR2(21),
    "CREATEWKGRPNAME" VARCHAR2(21),
    "TMGRPNAME" VARCHAR2(21),
    "TOPGRPNAME" VARCHAR2(21),
    "TMUSERNAME" VARCHAR2(21),
    "TOPUSERNAME" VARCHAR2(21),
    "LASTUPDUSERNAME" VARCHAR2(21),
    "CURINTROGNAME" VARCHAR2(22),
    "CURINTROUSERNAME" VARCHAR2(22),
    "CURETTRID" NUMBER,
    "CURLECNAME" VARCHAR2(21),
    "CUREXTRODTTM" DATE,
    "RESOLVEBYUSERNAME" VARCHAR2(21),
    "RESOLVEBYWKGRPNAME" VARCHAR2(21),
    "RESOLVEDBYUSERID" NUMBER,
    "RESOLVEDBYWKGRP" NUMBER,
    "NUMOFNEIDS" NUMBER,
    "PRINEIDLOCACTYNAME" VARCHAR2(40),
    "PRINEIDLOCZCTYNAME" VARCHAR2(40),
    "SYMPTCAT" VARCHAR2(32),
    "RECEIVEDVIA" VARCHAR2(32),
    "RECENTAPPERRORCODE" VARCHAR2(10),
    "CORPID" VARCHAR2(15),
    "KEYWORDS" VARCHAR2(25),
    "SLALEVEL" VARCHAR2(1),
    "ROGSTSCOMMENT" VARCHAR2(100),
    "TOGSTSCOMMENT" VARCHAR2(100),
    "TMGSTSCOMMENT" VARCHAR2(100),
    "CUSCNCTPAGER" VARCHAR2(47),
    "ALTCUSCNCTPAGER" VARCHAR2(47),
    "METANAMETBL" VARCHAR2(10),
    "NEXTACTIONDTTM" DATE,
    "TOPWKGRPSTATUS" VARCHAR2(10),
    "INTGRPID" VARCHAR2(21),
    "INTPUBFLAG" VARCHAR2(1),
    "INTTKTNUM" VARCHAR2(30),
    "BILLEVENTFLAG" VARCHAR2(1),
    "WHN_OTGTM" NUMBER DEFAULT 0,
    "ILEC_OTGTM" NUMBER DEFAULT 0,
    "EVENTID" VARCHAR2(15),
    "NUMCIRCUITS" NUMBER,
    "TMASSIGNDTTM" DATE,
    "TOPASSIGNDTTM" DATE,
    "ALERTCUSFLAG" VARCHAR2(1),
    "MCIPRODNAME" VARCHAR2(40),
    "ALTNEID" VARCHAR2(53),
    "CONTROLSITE" VARCHAR2(14),
    "CRITICALINDICATOR" VARCHAR2(1),
    "REPORTEDBYNAME" VARCHAR2(80),
    "REPORTEDBYPHN" VARCHAR2(22),
    "REPORTEDBYCELLPHN" VARCHAR2(21),
    "REPORTEDBYEMAIL" VARCHAR2(47),
    "REPORTEDBYFAXNUM" VARCHAR2(22),
    "REPORTEDBYHOMEPHN" VARCHAR2(22),
    "REPORTEDBYPAGER" VARCHAR2(47),
    "REPORTEDBYALTPHN" VARCHAR2(22),
    "DISPATCHIND" VARCHAR2(1),
    "BILLCUSTNOTIFY" VARCHAR2(1) DEFAULT 0,
    "ACCESSID" NUMBER DEFAULT 0 NOT NULL ENABLE,
    "GARMLEVEL" VARCHAR2(10) DEFAULT 1 NOT NULL ENABLE,
    "GARMID" VARCHAR2(100) DEFAULT ' ' NOT NULL ENABLE,
    "GARMIDTYPE" VARCHAR2(50) DEFAULT ' ' NOT NULL ENABLE,
    "T1AINDICATOR" VARCHAR2(15),
    "TKTSOURCE" VARCHAR2(20),
    "SOURCETEXT" VARCHAR2(40),
    "RCOCIRCUITID" VARCHAR2(53),
    "RCOTKTNUM" VARCHAR2(13)
    ) PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255 LOGGING
    STORAGE(INITIAL 134217728 NEXT 134217728
    BUFFER_POOL DEFAULT)
    TABLESPACE "TS_MED1"
    PARTITION BY RANGE ("TKTNUM")
    (PARTITION "PART_OLD" VALUES LESS THAN ('2003080100001')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 134217728 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_OLD" NOCOMPRESS ,
    PARTITION "PART04Q1" VALUES LESS THAN ('2004033199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 52428800 NEXT 52428800 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_04_OLD" NOCOMPRESS ,
    PARTITION "PART04Q2" VALUES LESS THAN ('2004063099999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 52428800 NEXT 52428800 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_04_OLD" NOCOMPRESS ,
    PARTITION "PART04Q3" VALUES LESS THAN ('2004093099999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 52428800 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_04_OLD" NOCOMPRESS ,
    PARTITION "PART04Q4" VALUES LESS THAN ('2004123199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 52428800 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_04_OLD" NOCOMPRESS ,
    PARTITION "PART05Q1Q2" VALUES LESS THAN ('2005063199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEADER_05Q1Q2" NOCOMPRESS ,
    PARTITION "PART05Q3Q4" VALUES LESS THAN ('2005123199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_05Q3Q4" NOCOMPRESS ,
    PARTITION "PART06Q1Q2" VALUES LESS THAN ('2006063199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_06Q1Q2" NOCOMPRESS ,
    PARTITION "PART06Q3Q4" VALUES LESS THAN ('2006123199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_06Q3Q4" NOCOMPRESS ,
    PARTITION "PART07Q1Q2" VALUES LESS THAN ('2007063199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_07Q1Q2" NOCOMPRESS ,
    PARTITION "PART07Q3Q4" VALUES LESS THAN ('2007123199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_07Q3Q4" NOCOMPRESS ,
    PARTITION "PART08Q1Q2" VALUES LESS THAN ('2008063199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_08Q1Q2" NOCOMPRESS ,
    PARTITION "PART08Q3Q4" VALUES LESS THAN ('2008123199999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_08Q3Q4" NOCOMPRESS ,
    PARTITION "PART09Q1Q2" VALUES LESS THAN ('2009063099999')
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_09Q1Q2" NOCOMPRESS ,
    PARTITION "PART09Q3Q4" VALUES LESS THAN (MAXVALUE)
    PCTFREE 20 PCTUSED 50 INITRANS 1 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_09Q3Q4" NOCOMPRESS )
    CREATE INDEX "ETMS"."XTKTHDR9" ON "ETMS"."T3TKTHEADER" ("LASTUPDDTTM", "INTPUB
    FLAG", "CURSTS")
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(
    BUFFER_POOL DEFAULT) LOCAL
    (PARTITION "PART_OLD"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 5242880 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_TKTHEAD_OLD" ,
    PARTITION "PART04Q1"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_04_OLD" ,
    PARTITION "PART04Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_04_OLD" ,
    PARTITION "PART04Q3"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_04_OLD" ,
    PARTITION "PART04Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 20971520 NEXT 20971520 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_04_OLD" ,
    PARTITION "PART05Q1Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 10485760 NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEADER_05Q1Q2" ,
    PARTITION "PART05Q3Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 10485760 NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_05Q3Q4" ,
    PARTITION "PART06Q1Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 5242880 NEXT 5242880 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_06Q1Q2" ,
    PARTITION "PART06Q3Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_06Q3Q4" ,
    PARTITION "PART07Q1Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_07Q1Q2" ,
    PARTITION "PART07Q3Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_07Q3Q4" ,
    PARTITION "PART08Q1Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_08Q1Q2" ,
    PARTITION "PART08Q3Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_08Q3Q4" ,
    PARTITION "PART09Q1Q2"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_09Q1Q2" ,
    PARTITION "PART09Q3Q4"
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "TS_IND_TKTHEAD_09Q3Q4" )
    PARALLEL 4
    DATA:
    2000120600662 06-Dec-2000 11:39:56 PM 12671 1243 UNKNOWN 5 11 0 1243 1243 -1 0 0 916 576 2675 06-Dec-2000 03:48:22 PM ANI CUSTOMER 0 0 -1 916 576 2675 0 06-Dec-2000 03:48:22 PM 0 06-Dec-2000 03:48:22 PM 0 0 0 0 CLOSED VOID 0 0 0 10-May-2001 10:17:18 PM 10873 unknown TXSAN.CSLOC TXSAN.CSLOC TXSAN.CSLOC 16-May-2008 05:50:29 PM unknowni TXSAN.CSLOC TXSAN.CSLOC TXSAN.CSLOC sburke 0 1 ALL PHONE 0 1
    2001021300976 23-Apr-2001 03:00:49 PM 50766 2113 UNKNOWN 5 2 0 2113 2113 -1 0 0 75fnode 13-Feb-2001 11:12:48 AM EQUIPMENT 0 0 1 75fnode 0 13-Feb-2001 11:12:48 AM 0 13-Feb-2001 11:12:48 AM 0 0 0 0 CLOSED VOID 0 0 0 22-May-2001 01:30:37 PM 10866 unknown MABST.3CMNOD MABST.3CMNOD MABST.3CMNOD 16-May-2008 05:50:29 PM unknown MABST.3CMNOD MABST.3CMNOD MABST.3CMNOD jcece 0 1 ALL PHONE 0 1
    2001022100287 21-Mar-2001 07:00:37 PM 62393 9974 UNKNOWN 5 14 0 9974 9974 -1 0 0 3P19S.S63.0031 20-Feb-2001 08:53:57 PM CIRCUIT CUSTOMER 0 0 0 -1 3P19S.S63.0031 0 20-Feb-2001 08:53:57 PM 0 20-Feb-2001 08:53:57 PM 0 0 0 0 CLOSED VOID 0 0 0 28-Apr-2001 03:47:18 PM 12782 mclement9486 CASAC.SSO CASAC.SSO CASAC.SSO 16-May-2008 05:50:29 PM mclement9486 CASAC.SSO CASAC.SSO CASAC.SSO unknown 0 01-Jan-1970 12:00:00 AM 1 ALL PHONE 1 N N 0 1
    2001022101367 21-Feb-2001 09:57:41 PM 42424 2935 UNKNOWN 5 4 0 2935 2935 -1 0 0 0808 105 0020 21-Feb-2001 10:46:50 AM SWITCHED CLI 0 0 -1 0808 105 0020 0 21-Feb-2001 10:46:50 AM 0 21-Feb-2001 10:46:50 AM 0 0 0 0 CLOSED VOID VOID 0 0 0 23-Apr-2001 05:54:57 PM 11063 unknown UKLN.CSCCO UKLN.CSCCO UKLN.CSCCO 16-May-2008 05:50:29 PM gharvey UKLN.CSCCO UKLN.CSCCO UKLN.CSCCO unknown 0 01-Jan-1970 12:00:00 AM 1 ALL PHONE 0 1
    Hope this helps.
    Thanks in advance,
    Arindam

  • Oracle based data warehouse creation

    Hi All ,
    I need to know Best Infrastructure for creating data warehouse. Our client is currenlty managing data in SQL Server,Oracle and XL sheets. Now they want to implement data warehouse,BI and Data mining.
    Scalability is our main concern because size of data will be in Tera Bytes (10 TB) in next few years. Scope is analysis,Impact analysis,Forecasting,GIS based analysis and mining(Trend analysis).
    Please suggess me on following point (I mean help me in tool selection):
    A. Storage
    B. Operating System, Database Server
    C. Other Server (Warehouse, Mining ,BI).
    D. Tools( Database ETL,OLAPReporting and Mining)
    I m working with Hyperion BI, I m new in data warehouse. This would be great if I get Cost of tools (for Perpectual licenses).
    Thanks in Advance
    Shiv

    Oracle Retail Data Model is independent of RDW and RGBU applications. It can be used with RMS and Point of Sale, but there is no pre-built ETL to load the data included with the product, although there are some options available thru partners.

  • Table partition based multiple date columns

    Hi , I am using Oracle 10G db. One of the source table has 26 million rows. Partition is based on business send date(Quaterly). Now the query that used to load the target table is based on ETL load date. Since the load date is not the partition column,the source query is taking long time to fetch.Can someone please suggest how to include ETL load date in the partition column or if any other way to improve the performance of the source query will be greatly appreciated.Thanks

    Partition is based on business send date(Quaterly).
    Can someone please suggest how to include ETL load date in the partition column
    Technically? Sure - just redefine the table (DBMS_REDEFINITION) and partition it on ETL load data.
    But someone partitioned on 'send date' for a reason didn't they? Don't you think you might want to find out WHY before you even think about changing it?
    The only info you have provided so far is that someone 'thinks' that a single query is 'taking long time to fetch'. That doesn't even mean anything. What is 'long time': 5 seconds, 5 days? How many rows are being fetched out of 26 million: 1, 20 million?
    1. post the table and index DDL
    2. post the query and execution plan
    3. post the command you executed to produce the stats on the table and indexes
    4. post the number of rows for the query predicates
    5. post info about the number of rows in the result set and what you are doing with them

  • Tablespaces and block size in Data Warehouse

    We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. The question is what are general advices in such considerations according table spaces and block size? I made some research and it is hard to find some clear answer, there are resources advising that block size is not important and can be left small (8 KB), others state that it is crucial and should be the biggest possible (64KB). The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
    Any help highly appreciated and thank you in advance.

    Wojtus-J wrote:
    We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. With little experience, the key feature is to avoid big mistakes - don't try to get too clever.
    The question is what are general advices in such considerations according table spaces and block size? If you need to ask about block sizes, use the default (i.e. 8KB).
    I made some research and it is hard to find some clear answer, But if you get contradictory advice from this forum, how would you decide which bits to follow ?
    A couple of sensible guidelines when researching on the internet - look for material that is datestamped with recent dates (last couple of years), or references recent - or at least relevant - versions of Oracle. Give preference to material that explains WHY an idea might be relevant, give greater preference to material that DEMONSTRATES why an idea might be relevant. Check that any explanations and demonstrations are relevant to your planned setup.
    The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
    It is often convenient, and sometimes very important, to separate data into different tablespaces based on some aspect of functionality. The performance thing was mooted (badly) in an era when discs were small and (disk) partitions were hard; but all your other examples of why to split are potentially valid for administrative. Big/Small, table/index, old/new, read-only/read-write, fact/dimension etc.
    For data warehouses a fairly common practice is to identify some sort of aging pattern for the data, and try to pick a boundary that allows you to partition data so that a large fraction of the data can eventually be made read-only: using tablespaces to mark time-boundaries can be a great convenience - note that the tablespace boundary need not match the partition boudary - e.g. daily partitions in a monthly tablespace. If you take this type of approach, you might have a "working" tablespace for recent data, and then copy the older data to "time-specific" tablespace, packing it and making it readonly as you do so.
    Tablespaces are (broadly speaking) about strategy, not performance. (Temporary tablespaces / tablespace groups are probably the exception to this thought.)
    Regards
    Jonathan Lewis

  • Why do we need SSIS and star schema of Data Warehouse?

    If SSAS in MOLAP mode stores data, what is the application of SSIS and why do we need a Data Warehouse and the ETL process of SSIS?
    I have a SQL Server OLTP database. I am using SSIS to transfer my SQL Server data from OLTP database to a Data Warehouse database that contains fact and dimension tables.
    After that I want to create cubes using SSAS form Data Warehouse data.
    I know that MOLAP stores data. Do I need any Data warehouse with Fact and Dimension tables?
    Is not it better to avoid creating Data warehouse and create cubes directly from OLTP database?

    Another thing to note is data stored in transactional system may not always be in end user consumable format for ex. we may use bit fields/flags to represent some details in OLTP as storage required ius minimum but presenting them as is would not make any
    sense to user as they would not know what each bit value represents. In such cases we apply some transformations and convert data into useful information for users to understand. This is also in the warehouse so that information in warehouse can directly be
    used for reporting. Also in many cases the report will merge data from multiple source systems so merging it on the fly in report would be tedious and would have hit on report server. In comparison bringing them onto common layer (warehouse) and prebuilding
    aggregates would be benefitial for the report performance.
    I think (not sure) we join tables in SSAS queries and calculate aggregations in it.
    I think SSAS stores these values and joined tables and we do not need to evaluates those values again and this behavior is like a Data Warehouse.
    Is not it?
    So if I do not need historical data, Can I avoid creating Data Warehouse?
    On the backend SSAS uses queries only to extract the data
    B/w I was not explaining on SSAS. I was explaining on what happens inside datawarehouse  which is a relational database by itself. SSAS is used to built cube (OLAP structures) on top of datawarehouse. star schema is easier for defining relationships
    and buidling aggregations inside SSAS as its simple and requires minimal lookups to be performed. Also data would be held at lowest granularity level which can easily be aggregated to required levels inside OLAP cubes. Cube processing is very resource
    intensive and using OLTP system would really have a huge impact on processing performance as its nnot denormalized and also doing tranformation etc on the fly adds up to complexity. Precreating a layer (data warehouse) having data in required format would
    make cube processing easier and simpler as it has to just cross join tables and aggregate data based on relationships defined and level needed inside the cube.
    Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

  • OBIEE reverse engineering to go from SQL Server to a data warehouse

    Hi,
    I'm new to data modeling for warehouses. We currently have an OBIEE environment set up where the data source was SQL Server transactional tables. The SQL Server data is to be moved to a non-Oracle data warehouse and I need to produce a logical data model for the warehouse folks at my company. Unfortunately, the SQL Server data was never modeled, so, I'm basing the model from the Logical and Physical diagram/relationships of OBIEE.
    My question is in regards to the validity of the following relationship to be used in a data warehouse based on what's currently in OBIEE. When I model this via Erwin, I'm wondering if I'm way off base in the relationships (modeling, not personal):
    Dimension 1 has a 0:M with Dimension 2
    Dimension 1 has a 0:M with Dimesion 3
    Dimension 2 has a 0:M with Dimension 3
    Both Dimension 2 and Dimension 3 have a 0:M with Fact 1
    Through the use of aliases and such, this does work in OBIEE. Will this work as a data model for a data warehouse environment?
    Thanks!

    I think you started with the wrong foot. I suggest you search in Google for "kimball methodology" and have a read at a few articles. Your DWH model should not be based on your transactional tables. You should ask your business users what "questions" they want to answer in the DWH. Then model your DWH base on that. You can not model a DWH without knowing what questions you need to answer. For instance if your business users want to know the sales per day and per branch you will a sales fact with a sales amount measure joining to two dimensions branch and time dimension. The number of facts will depend on the questions you need to answer, the type of data and the granularity of them.

  • Data Access Object for Data Warehouse?

    Hi,
    Does anyone know how the DAO pattern looks like when it is used for a data warehouse rather than a normal transactional database?
    Normally we have something like CustomerDAO or ProductDAO in the DAO pattern, but for data warehouse applications, JOINs are used and multiple tables are queried, for example, a query may contains data from the Customer, Product and Time table, what should the DAO class be named? CustomerProductTimeDAO?? Any difference in other parts of the pattern?
    Thanks in advance.
    SK

    In my opinion, there are no differences in the Data Access Object design pattern which have any thing to do with any characteristic of its implementation or the storage format of the data the pattern is designed to function with.
    The core pupose of the DAO design pattern is to encapsulate data access code and separate it from the business logic code of the application. A DAO implementation might vary from application to application. The design pattern does not specify any implementation details. A DAO implementation can be applied to group of XML data files, an Excel-based CSV file, a relational database, or an OS file system. The design is the same for all these, it is the implementation that varies.
    The core difference between an operational database and a strategic data warehouse is the purpose of why and how the data is used. It is not so much a technical difference. The relational design may vary however, there may be more tables amd ternary relationships in a data warehouse to support more fine-tuned queries; there may be less tables in a operational database to support insert/add efficiencies.
    The DAO implementation for a data warehouse would be based on the model of the databases. However the tables are set up, that is how the DAO is coded.

  • Data Warehouse Infrastructure

    I have a requirement to build a Data Warehouse and Analytics / Reporting capability with the following requirements...
    Maximum of 1TB for Production Data + DR + Test/Dev Env.
    SSIS (up to 25 sources), SSAS (cubes, 5 concurrent users) and SSRS (2 concurrent users, max 500 reports).
    I needs a Production, DR and Test/Dev Environment 
    I have been told that I will require 12 servers each having 4 cores and 12GB of storage (4 for Prod, 4 DR and 4 Test/Dev).
    To give you an idea of load we plan to have 1 full time ETL developer, 5 Data Analysts, 2 Reporting Analysts. We are quite a small business and don't have a particularly large
    amount of data. 
    The model has SQL Server, SSIS, SSAS, SSRS on different servers across each Environment. 
    Any idea if this is overkill? I also have an estimate of 110 days for Setting up the Servers, Installing the SQL Server software and general Infrastructure design activity.

    Agree. Overkill. Big overkill.
    I would recommend production/DR/Dev each have 2 servers. I'd put SSAS, SSRS and SSIS one one and the DB on the other.
    In production, SSAS/SSRS will be active during the daytime; SSIS will likely be active off hours. So putting all that on one box should be fine for sharing the load. The DB on a second box would be good since it will likely be busy during the daytime
    and night time. Four processors may be heavy depending on the types of queries and usage patterns. I suspect you can get by with 2 processor servers, but would recommend buying the 4 processor boxes for dev and production, get them configured and run
    some performance baselines before putting in the DR environment. Then, if you find the CPUs idling, you can always cut the DR environment to 2 processor boxes. Not sure it's worth the minor cost savings to save 2 processors on 2 boxes with that effort, but
    if you're looking to cut corners, you may find that a 2 processor per server DR environment is within your performance comfort zone.
    For the dev environment, one box may well handle it all, but I'd go for 2. On average, a Dev environment isn't all that busy, but when you need the horsepower, you need it. And since it's Development AND Test, you help yourself by having realistic production
    level performance on what you're testing. Four processors is fine, but max it out on memory.
    As for hard drives, be careful about configuration. You need the space on your DW server and maybe for the SSAS server depending on how the cubes are built (ROLAP/MOLAP). When you speak about amounts of data, be careful since you'll want a lot of indexes,
    and that can double the DB size for a DW. Your DW will also run faster if you have different filegroups for data/indexes/temp DB, but only if those different filegroups are on different physical media that work well in parallel. You can always get fancier
    with more filegroups to have different ones for staging tables, for segregating fact & dimension tables etc. But for this size DB, that's overkill as well.
    Mainly, I'd look at spending hardware $s on memory for the servers, but get less of them.
    Now... two questions...
    1) Can you clarify the disk space needs? How much total data space in one environment, without indexes? Based on that, add the same for indexes, add half as much (?) for TempDB and you have the core disk needs. Depending on how much it is,
    you can decide on RAID, filegroup configuration, etc. And if the disk space with indexes is small enough that it all fits in memory, then disk and filegroup configuration becomes inconsequential except for ETL loads.
    2) The 25 sources... can you clarify that? 25 source systems? Total of 25 source applications? Total of 25 tables? Curious, because I'm wondering about how long you'd keep 1 full time ETL developer busy.

  • What Master Data to hold within a Data Warehouse

    Hi,
    We are developing a data warehouse which will incorporate Master Data entities. We have a pre-existing Master Data Management solution which will be the system of source for MD within the DW & associated Data Marts. We have decided to have a copy
    of the MD within the DW. However we are of two schools of thought on what data should be held.
    One school says that only those attributes that shapes a query result should be held in the DW-MD the second says that All MD that may be used by a reporting system should be held within the DW so that it is the single source of data for the reporting
    application. let me give an example. Let’s say we have a Customer MD entity with the following attributes
    Customer
    ID
    NAME
    COUNTRY *
    EMAIL ADDR
    CITY *
    PHONE NUM
    GENDER *
    LAST LOGGED IN
    FAX ADDR
    DATE OF JOINING *
          LOGO (binary)
    Now, we will never do a query based on phone number, fax or email address etc. But the attributes flagged by a
    * will shape queries when coupled with our facts. Such as "find all male customers with 4 or more transactions over $1000" or "find all customers registered from 2007 based in New York who have purchased an X". However when
    showing the results we will always show the full customer profile including Name, email address etc. (I realise the queries are very specific and not report queries as such but they suffice for the question at hand)
    The first schools says only the query shaping MD elements should form the MD within the DW and that the reporting application should obtain the remainder directly from the group MD system as required. The second school says that the DW (or the DM) should
    furnish all the MD required by the application. My question is which of the two approaches is considered best practice and as importantly, why?
    Cheers,
    Daryl

    Do you have ODS? NDS?...? or you just have Data warehouse as the only resource for covering reports and dashboards?
    if you do have only the Data Warehouse then you have to cover
    all report's requirements within the data warehouse, no matter it used in the filter/slicing dicing/or as display only field. So I would add those fields such as names, email address, phone number, as attributes in the data warehouse. But I will only
    consider indexing and data warehouse best practices for performance tuning for attributes that participate in slicing and dicing and filtering (such as country, year....).
    on the other hand; if you use SSAS multi-dimensional cube on top of your data warehouse, then you can set some attributes to be only visible (attributes for display only), and some of them to be visible and hierarchy enabled (attributes that participate
    in slicing and dicing and filtering).
    Regards,
    Reza
    SQL Server MVP
    Blog:  
    http://rad.pasfu.com  Twitter:
      LinkedIn:
    SQL Server Integration Services 2012 Tutorial Videos:
    http://www.radacad.com/CoursePlan.aspx?course=1

  • Efficiency of data warehouse sql and star/snowflake schema

    Hi,
    We are using 11.2.0.3 and need to improve query performance of reports.  data warehouse star/snowflake schema
    In addition to indexing, partitioning having star_transformation enabled etc I am condisriing impact of the following on query performance.
    central fact (over a billion rows) joins to a dimesnion customer ( few hundred thousand rows) which in turn joined to latest version of the dimesnion ( whichhas circa 30,000 rows).
    The table with few hundred thousand rows (customer dimesnion) must alwsys be queried as data stored aganist the version of customer applicable at the time - we just query latest_customer as users want to see
    latest version of customer attributes to stop data being fragemented across several rows in the report.
    Considering if would be more efficient to create a dimenson which is the equivalent of customer but also stores the latest version of the customer attributes on the on row - this would mean customer dimensuion would have far more columns but queries would could avoid additional lookup of this 30k row table.
    Thoughts are - would this be a material benefit?
    At monent users would query latest_customer to say get all customers belonging to a certain multiple chain.
    If change as above then they would query directly the customer dimension with few hundred thousand rows.
    Thoughts?
    Thanks

    We are using 11.2.0.3 and need to improve query performance of reports.  data warehouse star/snowflake schema
    That is NOT a realistic or even meaningful goal.
    And until you identify and document an actual PROBLEM or specific goal you should not even be considering possible solutions.
    Anything you do to improve one report might degrade the performance of several other reports.
    You need to start over and gather information about WHAT Oracle is doing for the reports now, HOW that work is being done and capture metrics that validate how the reports are currently performing.
    Your first step should be to document the performance you are getting now for each report.
    The second step would be to identify which of those reports is a possible target for tuning.
    The third step is to prioritize the reports: which is most important to tune, which is next, etc.
    Then you need to generate the execution plans for those reports to identify EXACTLY how Oracle is executing the queries now.
    At this point you should have enough information to know what your possible options are.
    So then you create a prioritized list of options. The top of the list should be additions to what you already have.
    1. New indexes - regular or bitmapped (if appropriate)
    2. Dropping indexes that aren't being used.
    3. Report-ready summary tables or Materializeds views.
    IMHO modifying your basic architecture should be your LAST resort and undertaken only if you can't solve your (unstated) problem using solutions that have less impact and risk.

  • Best practice of metadata table in data warehouse environment ?

    Hi guru's,
    In datawarehouse, we have 1. Stage schema 2. DWH(Data warehouse reporting schema). In stageing we have about 300 source tables. In DWH schema, we are creating the tables which are only required from reporting prespective . some of the tables in stageing schema, have been created in DWH schema as well with different table name and column names. The naming convention for these same tables and columns in DWH schema is more based on business names.
    In order to keep track of these tables we are creating metadata table in DWH schema say for example
    Stage                DWH_schema
    Table_1             Table_A         
    Table_2             Table_b
    Table_3             Table_c
    Table_4              Table_DMy question is how do we handle the column names in each of these tables. The stage_1, stage_2 and stage_3 column names have been renamed in DWH_schema which are part of Table_A, Table_B, Table_c.
    As said earlier, we have about 300 tables in stage and may be around 200 tables in DWH schema. Lot of the column names have been renamed in DWH schema from stage tables. In some of the tables we have 200 column's
    so my concern is how do we handle the column names in metadata table ? Do we need to keep only table names in metadata table not column names ?
    Any idea will be greatly appriciated.
    Thanks!

    hi
    seems quite a buzzing question.
    In our project we designed a hub and spoke like architecture.
    Thus we have 3 layer, L0 is the one closest to the source and L0 table's name are linked to the corresponding sources names by mean of naming standard (like tabA EXT_tabA tabA_OK1 so on based on implementation of load procedures).
    At L1 we have the ODS , normalized model , we use business names for table there and standard names for temporary structures and artifacts
    Both L0 an L1 keep source's column names as general rule, new columns like calculated one are business driven and metadata are standard driven.
    Datamodeler fits perfect for modelling L1 purpose.
    L2 is the dimensional schema business names take place for tables and columns eventually rewritten at presentation layer ( front end tool )
    hope this helps D.

  • Please help to get onhand stock report with last purchase and billed date warehouse and item wise

    please help to get onhand stock report with last purchase and billed date warehouse and item wise

    Hi Rajeesh Ambadi...
    Try This
    SELECT distinct T0.ITEMCODE , t1.ItemName, T0.ONHAND as 'Total Qty',  
      T1.LASTPURDAT ,t1.LastPurPrc
    FROM OITW T0 INNER JOIN OITM T1 ON T0.ITEMCODE = T1.ITEMCODE
    INNER JOIN OITB T2 ON T1.ITMSGRPCOD=T2.ITMSGRPCOD left join ibt1 t3 on t3.itemcode = t0.itemcode and t3.whscode = t0.whscode
    WHERE
    T0.ONHAND>0
    AND T0.WhsCode ='[%0]'
    Hope Helpful
    Regards
    Kennedy

  • What are the best solutions for data warehouse configuration in 10gR2

    I need help on solutions to be provided to my Client for upgrading the data warehouse.
    Current Configuration: Oracle database 9.2.0.8. This database contains the data warehouse and one more data mart on the same host.Sizes are respectively 6 Terabyte(retention policy of 3 years+current year) and 1 Terabyte. The ETL tool and BO Reporting tools are also hosted on the same host. This current configuration is really performing poor.
    Client cannot go for a major architectural or configuration changes to its existing environment now due to some constraints.
    However, they have agreed to separate out the databases on separate hosts from the ETL tools and BO objects. Also we are planning to upgrade the database to 10gR2 to attain stability, better performance and overcome current headaches.
    We cannot upgrade the database to 11g as the BO is at a version 6.5 which isn't compatible with Oracle 11g. And Client cannot afford to upgrade anything else other than the database.
    So, my role is very vital in providing a perfect solution towards better performance and take a successful migration of Oracle Database from one host to another (similar platform and OS) in addition to upgrade.
    I have till now thought of the following:
    Move the Oracle database and data mart to separate host.
    The host will be the same platform, that is, HP Superdome with HP-UX 32-bit OS (we cannot change to 64-bit as ETL tool doesn't support)
    Install new Oracle database 10g on the new host and move the data to it.
    Exploring all new features of 10gR2 to help data warehouse, that is, SQL MODEL Clause introduction, Parallel processing, Partitioning, Data Pump, SPA to study pre and post migrations.
    Also thinking of RAC to provide more better solution as our main motive is to show a tremendous performance enhancement.
    I need all your help to prepare a good road map for my assignment. Please suggest.
    Thanks,
    Tapan

    SGA=27.5 GB and PGA=50 MB
    Also I am pasting part of STATSPACK Report, eliminating the snaps of DB bounce. Please suggest the scope of improvement in this case.
    STATSPACK report for
    Snap Id Snap Time Sessions Curs/Sess Comment
    Begin Snap: 582946 11-Mar-13 20:02:16 46 12.8
    End Snap: 583036 12-Mar-13 18:24:24 60 118.9
    Elapsed: 1,342.13 (mins)
    Cache Sizes (end)
    ~~~~~~~~~~~~~~~~~
    Buffer Cache: 21,296M Std Block Size: 16K
    Shared Pool Size: 6,144M Log Buffer: 16,384K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 1,343,739.01 139,883.39
    Logical reads: 100,102.54 10,420.69
    Block changes: 3,757.42 391.15
    Physical reads: 6,670.84 694.44
    Physical writes: 874.34 91.02
    User calls: 1,986.04 206.75
    Parses: 247.87 25.80
    Hard parses: 5.82 0.61
    Sorts: 1,566.76 163.10
    Logons: 10.99 1.14
    Executes: 1,309.79 136.35
    Transactions: 9.61
    % Blocks changed per Read: 3.75 Recursive Call %: 43.34
    Rollback per transaction %: 3.49 Rows per Sort: 190.61
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.90 Redo NoWait %: 100.00
    Buffer Hit %: 96.97 In-memory Sort %: 100.00
    Library Hit %: 99.27 Soft Parse %: 97.65
    Execute to Parse %: 81.08 Latch Hit %: 99.58
    Parse CPU to Parse Elapsd %: 3.85 % Non-Parse CPU: 99.34
    Shared Pool Statistics Begin End
    Memory Usage %: 7.11 50.37
    % SQL with executions>1: 62.31 46.46
    % Memory for SQL w/exec>1: 26.75 13.47
    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    CPU time 492,062 43.66
    db file sequential read 157,418,414 343,549 30.49
    library cache pin 92,339 66,759 5.92
    PX qref latch 63,635 43,845 3.89
    db file scattered read 2,506,806 41,677 3.70
    Background Wait Events for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    -> ordered by wait time desc, waits desc (idle events last)
    Avg
    Total Wait wait Waits
    Event Waits Timeouts Time (s) (ms) /txn
    log file sequential read 176,386 0 3,793 22 0.2
    log file parallel write 2,685,833 0 1,813 1 3.5
    db file parallel write 239,166 0 1,350 6 0.3
    control file parallel write 33,432 0 79 2 0.0
    LGWR wait for redo copy 478,120 536 75 0 0.6
    rdbms ipc reply 10,027 0 47 5 0.0
    control file sequential read 32,414 0 40 1 0.0
    db file scattered read 4,101 0 30 7 0.0
    db file sequential read 13,946 0 29 2 0.0
    direct path read 203,694 0 14 0 0.3
    log buffer space 363 0 13 37 0.0
    latch free 3,766 0 9 2 0.0
    direct path write 80,491 0 6 0 0.1
    async disk IO 351,955 0 4 0 0.5
    enqueue 28 0 1 21 0.0
    buffer busy waits 1,281 0 1 0 0.0
    log file single write 172 0 0 1 0.0
    rdbms ipc message 10,563,204 251,286 992,837 94 13.7
    pmon timer 34,751 34,736 78,600 2262 0.0
    smon timer 7,462 113 76,463 10247 0.0
    Instance Activity Stats for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    Statistic Total per Second per Trans
    CPU used by this session 49,206,154 611.0 63.6
    CPU used when call started 49,435,735 613.9 63.9
    CR blocks created 6,740,777 83.7 8.7
    Cached Commit SCN referenced 423,253,503 5,256.0 547.2
    Commit SCN cached 19,165 0.2 0.0
    DBWR buffers scanned 48,276,489 599.5 62.4
    DBWR checkpoint buffers written 6,959,752 86.4 9.0
    DBWR checkpoints 454 0.0 0.0
    DBWR free buffers found 44,817,183 556.5 57.9
    DBWR lru scans 137,149 1.7 0.2
    DBWR make free requests 162,528 2.0 0.2
    DBWR revisited being-written buff 4,220 0.1 0.0
    DBWR summed scan depth 48,276,489 599.5 62.4
    DBWR transaction table writes 5,036 0.1 0.0
    DBWR undo block writes 2,989,436 37.1 3.9
    DDL statements parallelized 3,723 0.1 0.0
    DFO trees parallelized 4,157 0.1 0.0
    DML statements parallelized 3 0.0 0.0
    OS Block input operations 29,850 0.4 0.0
    OS Block output operations 1,591 0.0 0.0
    OS Characters read/written 182,109,814,791 2,261,447.1 235,416.9
    OS Integral unshared data size ################## 242,463,432.4 ############
    OS Involuntary context switches 188,257,786 2,337.8 243.4
    OS Maximum resident set size 43,518,730,619 540,417.4 56,257.5
    OS Page reclaims 159,430,953 1,979.8 206.1
    OS Signals received 5,260,938 65.3 6.8
    OS Socket messages received 79,438,383 986.5 102.7
    OS Socket messages sent 93,064,176 1,155.7 120.3
    OS System time used 10,936,430 135.8 14.1
    OS User time used 132,043,884 1,639.7 170.7
    OS Voluntary context switches 746,207,739 9,266.4 964.6
    PX local messages recv'd 55,120,663 684.5 71.3
    PX local messages sent 55,120,817 684.5 71.3
    Parallel operations downgraded 1 3 0.0 0.0
    Parallel operations not downgrade 4,154 0.1 0.0
    SQL*Net roundtrips to/from client 155,422,335 1,930.0 200.9
    SQL*Net roundtrips to/from dblink 18 0.0 0.0
    active txn count during cleanout 16,529,551 205.3 21.4
    background checkpoints completed 43 0.0 0.0
    background checkpoints started 43 0.0 0.0
    background timeouts 280,202 3.5 0.4
    branch node splits 4,428 0.1 0.0
    buffer is not pinned count 6,382,440,322 79,257.4 8,250.7
    buffer is pinned count 9,675,661,370 120,152.8 12,507.9
    bytes received via SQL*Net from c 67,384,496,376 836,783.4 87,109.3
    bytes received via SQL*Net from d 6,142 0.1 0.0
    bytes sent via SQL*Net to client 50,240,643,657 623,890.4 64,947.1
    bytes sent via SQL*Net to dblink 3,701 0.1 0.0
    calls to get snapshot scn: kcmgss 145,385,064 1,805.4 187.9
    calls to kcmgas 36,816,132 457.2 47.6
    calls to kcmgcs 3,514,770 43.7 4.5
    change write time 369,373 4.6 0.5
    cleanout - number of ktugct calls 20,954,488 260.2 27.1
    cleanouts and rollbacks - consist 6,357,174 78.9 8.2
    cleanouts only - consistent read 10,078,802 125.2 13.0
    cluster key scan block gets 69,403,565 861.9 89.7
    Instance Activity Stats for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    Statistic Total per Second per Trans
    cluster key scans 41,311,211 513.0 53.4
    commit cleanout failures: block l 413,776 5.1 0.5
    commit cleanout failures: buffer 414 0.0 0.0
    commit cleanout failures: callbac 41,194 0.5 0.1
    commit cleanout failures: cannot 174,382 2.2 0.2
    commit cleanouts 11,469,056 142.4 14.8
    commit cleanouts successfully com 10,839,290 134.6 14.0
    commit txn count during cleanout 17,155,424 213.0 22.2
    consistent changes 145,418,277 1,805.8 188.0
    consistent gets 8,043,252,188 99,881.4 10,397.7
    consistent gets - examination 3,180,028,047 39,489.7 4,110.9
    current blocks converted for CR 9 0.0 0.0
    cursor authentications 14,926 0.2 0.0
    data blocks consistent reads - un 143,706,500 1,784.6 185.8
    db block changes 302,577,666 3,757.4 391.2
    db block gets 336,562,217 4,179.4 435.1
    deferred (CURRENT) block cleanout 2,912,793 36.2 3.8
    dirty buffers inspected 627,174 7.8 0.8
    enqueue conversions 1,296,337 16.1 1.7
    enqueue releases 13,053,200 162.1 16.9
    enqueue requests 13,239,092 164.4 17.1
    enqueue timeouts 185,878 2.3 0.2
    enqueue waits 114,120 1.4 0.2
    exchange deadlocks 7,390 0.1 0.0
    execute count 105,475,101 1,309.8 136.4
    free buffer inspected 1,604,407 19.9 2.1
    free buffer requested 258,126,047 3,205.4 333.7
    hot buffers moved to head of LRU 22,793,576 283.1 29.5
    immediate (CR) block cleanout app 16,436,010 204.1 21.3
    immediate (CURRENT) block cleanou 2,860,013 35.5 3.7
    index fast full scans (direct rea 12,375 0.2 0.0
    index fast full scans (full) 3,733 0.1 0.0
    index fast full scans (rowid rang 192,148 2.4 0.3
    index fetch by key 1,321,024,486 16,404.5 1,707.7
    index scans kdiixs1 406,165,684 5,043.8 525.1
    leaf node 90-10 splits 50,373 0.6 0.1
    leaf node splits 697,235 8.7 0.9
    logons cumulative 884,756 11.0 1.1
    messages received 3,276,719 40.7 4.2
    messages sent 3,257,171 40.5 4.2
    no buffer to keep pinned count 569 0.0 0.0
    no work - consistent read gets 4,406,092,172 54,715.0 5,695.8
    opened cursors cumulative 20,527,704 254.9 26.5
    parse count (failures) 267,088 3.3 0.4
    parse count (hard) 468,996 5.8 0.6
    parse count (total) 19,960,548 247.9 25.8
    parse time cpu 323,024 4.0 0.4
    parse time elapsed 8,393,422 104.2 10.9
    physical reads 537,189,332 6,670.8 694.4
    physical reads direct 292,545,140 3,632.8 378.2
    physical writes 70,409,002 874.3 91.0
    physical writes direct 59,248,394 735.8 76.6
    physical writes non checkpoint 69,103,391 858.1 89.3
    pinned buffers inspected 11,893 0.2 0.0
    prefetched blocks 95,892,161 1,190.8 124.0
    prefetched blocks aged out before 1,495,883 18.6 1.9
    Instance Activity Stats for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    Statistic Total per Second per Trans
    process last non-idle time ################## ############## ############
    queries parallelized 417 0.0 0.0
    recursive calls 122,323,299 1,519.0 158.1
    recursive cpu usage 3,144,533 39.1 4.1
    redo blocks written 180,881,558 2,246.2 233.8
    redo buffer allocation retries 5,400 0.1 0.0
    redo entries 164,728,513 2,045.6 213.0
    redo log space requests 1,006 0.0 0.0
    redo log space wait time 2,230 0.0 0.0
    redo ordering marks 2,563 0.0 0.0
    redo size 108,208,614,904 1,343,739.0 139,883.4
    redo synch time 558,520 6.9 0.7
    redo synch writes 2,343,824 29.1 3.0
    redo wastage 1,126,585,600 13,990.0 1,456.4
    redo write time 718,655 8.9 0.9
    redo writer latching time 7,763 0.1 0.0
    redo writes 2,685,833 33.4 3.5
    rollback changes - undo records a 522,742 6.5 0.7
    rollbacks only - consistent read 335,177 4.2 0.4
    rows fetched via callback 1,100,990,382 13,672.1 1,423.3
    session connect time ################## ############## ############
    session cursor cache count 1,061 0.0 0.0
    session cursor cache hits 1,687,796 21.0 2.2
    session logical reads 8,061,057,193 100,102.5 10,420.7
    session pga memory 1,573,228,913,832 19,536,421.0 2,033,743.8
    session pga memory max 1,841,357,626,496 22,866,054.4 2,380,359.0
    session uga memory 1,074,114,630,336 13,338,399.4 1,388,529.0
    session uga memory max 386,645,043,296 4,801,374.0 499,823.6
    shared hash latch upgrades - no w 410,360,146 5,095.9 530.5
    sorts (disk) 2,657 0.0 0.0
    sorts (memory) 126,165,625 1,566.7 163.1
    sorts (rows) 24,048,783,304 298,638.8 31,088.3
    summed dirty queue length 5,438,201 67.5 7.0
    switch current to new buffer 1,302,798 16.2 1.7
    table fetch by rowid 6,201,503,534 77,010.5 8,016.8
    table fetch continued row 26,649,697 330.9 34.5
    table scan blocks gotten 1,864,435,032 23,152.6 2,410.2
    table scan rows gotten 43,639,997,280 541,923.3 56,414.3
    table scans (cache partitions) 26,112 0.3 0.0
    table scans (direct read) 246,243 3.1 0.3
    table scans (long tables) 340,200 4.2 0.4
    table scans (rowid ranges) 359,617 4.5 0.5
    table scans (short tables) 9,111,559 113.2 11.8
    transaction rollbacks 4,819 0.1 0.0
    transaction tables consistent rea 824 0.0 0.0
    transaction tables consistent rea 1,386,848 17.2 1.8
    user calls 159,931,913 1,986.0 206.8
    user commits 746,543 9.3 1.0
    user rollbacks 27,020 0.3 0.0
    write clones created in backgroun 7 0.0 0.0
    write clones created in foregroun 4,350 0.1 0.0
    Buffer Pool Statistics for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    -> Standard block size Pools D: default, K: keep, R: recycle
    -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
    Free Write Buffer
    Number of Cache Buffer Physical Physical Buffer Complete Busy
    P Buffers Hit % Gets Reads Writes Waits Waits Waits
    D 774,144 95.6############ 233,869,082 10,089,734 0 0########
    K 504,000 99.9############ 3,260,227 1,070,338 0 0 65,898
    R 63,504 96.2 196,079,539 7,511,863 535 0 0 0
    Buffer wait Statistics for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    -> ordered by wait time desc, waits desc
    Tot Wait Avg
    Class Waits Time (s) Time (ms)
    data block 7,791,121 14,676 2
    file header block 587 101 172
    undo header 151,617 71 0
    segment header 299,312 58 0
    1st level bmb 45,235 7 0
    bitmap index block 392 1 3
    undo block 4,250 1 0
    2nd level bmb 14 0 0
    system undo header 2 0 0
    3rd level bmb 1 0 0
    Latch Activity for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    ->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
    willing-to-wait latch get requests
    ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
    ->"Pct Misses" for both should be very close to 0.0
    Pct Avg Wait Pct
    Get Get Slps Time NoWait NoWait
    Latch Requests Miss /Miss (s) Requests Miss
    Consistent RBA 2,686,230 0.0 0.2 0 0
    FAL request queue 86 0.0 0 0
    FAL subheap alocation 0 0 2 0.0
    FIB s.o chain latch 1,089 0.0 0 0
    FOB s.o list latch 4,589,986 0.5 0.0 2 0
    NLS data objects 1 0.0 0 0
    SQL memory manager worka 5,963 0.0 0 0
    Token Manager 0 0 2 0.0
    active checkpoint queue 719,439 0.3 0.1 0 1 0.0
    alert log latch 184 0.0 0 2 0.0
    archive control 4,365 0.0 0 0
    archive process latch 1,808 0.6 0.6 0 0
    begin backup scn array 3,387,572 0.0 0.0 0 0
    cache buffer handles 1,577,222 0.2 0.0 0 0
    cache buffers chains ############## 0.5 0.0 430 354,357,972 0.3
    cache buffers lru chain 17,153,023 0.1 0.0 1 385,505,654 0.5
    cas latch 538,804,153 0.3 0.0 7 0
    channel handle pool latc 1,776,950 0.5 0.0 0 0
    channel operations paren 2,901,371 0.3 0.0 0 0
    checkpoint queue latch 99,329,722 0.0 0.0 0 11,153,369 0.1
    child cursor hash table 3,927,427 0.0 0.0 0 0
    commit callback allocati 8,739 0.0 0 0
    dictionary lookup 7,980 0.0 0 0
    dml lock allocation 6,767,990 0.1 0.0 0 0
    dummy allocation 1,898,183 0.2 0.1 0 0
    enqueue hash chains 27,741,348 0.1 0.1 4 0
    enqueues 17,450,161 0.3 0.1 6 0
    error message lists 132,828 2.6 0.2 1 0
    event group latch 884,066 0.0 0.7 0 0
    event range base latch 1 0.0 0 0
    file number translation 34 38.2 0.9 0 0
    global tx hash mapping 577,859 0.0 0 0
    hash table column usage 4,062 0.0 0 8,757,234 0.0
    hash table modification 16 0.0 0 2 0.0
    i/o slave adaptor 0 0 2 0.0
    job workq parent latch 4 100.0 0.3 0 494 8.7
    job_queue_processes para 1,950 0.0 0 2 0.0
    ksfv messages 0 0 4 0.0
    ktm global data 8,219 0.0 0 0
    lgwr LWN SCN 2,687,862 0.0 0.0 0 0
    library cache 310,882,781 0.9 0.0 34 104,759 4.0
    library cache load lock 30,369 0.0 0.3 0 0
    library cache pin 153,821,358 0.1 0.0 2 0
    library cache pin alloca 126,316,296 0.1 0.0 4 0
    list of block allocation 2,730,808 0.3 0.0 0 0
    loader state object free 566,036 0.1 0.0 0 0
    longop free list parent 197,368 0.0 0 8,390 0.0
    message pool operations 14,424 0.0 0.0 0 0
    messages 25,931,764 0.1 0.0 1 0
    mostly latch-free SCN 40,124,948 0.3 0.0 5 0
    Latch Sleep breakdown for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    -> ordered by misses desc
    Get Spin &
    Latch Name Requests Misses Sleeps Sleeps 1->4
    cache buffers chains ############## 74,770,083 1,062,119 73803903/884
    159/71439/10
    582/0
    redo allocation 170,107,983 3,441,055 149,631 3292872/1467
    48/1426/9/0
    library cache 310,882,781 2,831,747 89,240 2754499/6780
    6/7405/2037/
    0
    shared pool 158,471,190 1,755,922 55,268 1704342/4836
    9/2826/385/0
    cas latch 538,804,153 1,553,992 6,927 1547125/6808
    /58/1/0
    row cache objects 161,142,207 1,176,998 27,658 1154070/1952
    0/2560/848/0
    process queue reference 1,893,917,184 1,119,215 106,454 78758/4351/1
    36/0/0
    Library Cache Activity for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    ->"Pct Misses" should be very low
    Get Pct Pin Pct Invali-
    Namespace Requests Miss Requests Miss Reloads dations
    BODY 3,137,721 0.0 3,137,722 0.0 0 0
    CLUSTER 6,741 0.1 4,420 0.2 0 0
    INDEX 353,708 0.8 361,065 1.2 0 0
    SQL AREA 17,052,073 0.3 54,615,678 0.9 410,682 19,628
    TABLE/PROCEDURE 3,521,884 0.2 12,922,737 0.1 619 0
    TRIGGER 1,975,977 0.0 1,975,977 0.0 1 0
    SGA Memory Summary for DB: P7IN1 Instance: P7IN1 Snaps: 582946 -583036
    SGA regions Size in Bytes
    Database Buffers 22,330,474,496
    Fixed Size 779,288
    Redo Buffers 17,051,648
    Variable Size 7,180,648,448
    sum 29,528,953,880

Maybe you are looking for