Re: Table design
- From: Hans Forbrich <fuzzy.graybeard@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 28 Jan 2013 18:11:56 -0700
Are you thinking about the redesign *because* of the chained rows? If
so, why is this worrying you? (My reasoning - with the number of CLOBS
you have in some of those tables, I don't see you significantly avoiding
chained rows in any case, as long as they are inline.)
If you split the tables vertically, how often will you end up
recombining (joining) to make the application happy? What will that cost
(in i/o)?
Have you considered moving the CLOBS off to LOB segments?
How many of the principles from the SecureFiles and Large Object
Developer's Guide
(http://www.oracle.com/pls/db112/portal.portal_db?selected=5&frame=#application_development_concepts)
have you put into practice?
/Hans
On 28/01/2013 4:35 PM, Raju Angani wrote:
> Hi,
> I have 2 tables in a schema of 800+ tables with column count of 60+. I see
> lot of chained rows in all 3 tables.
> I'm thinking of restructing the tables as multiple tables, also considering
> using cluster(create cluster). read about clustering table not good for lot
> of updates.
>
> ...
> c30 INTEGER NOT NULL,
> c31 INTEGER NOT NULL,
> c32 NCLOB,
> c33 NCLOB,
> c34 DATE,
> c35 DATE,
> c36 NVARCHAR2(21),
> c37 NCLOB,
> c38 NVARCHAR2(21),
> c39 INTEGER,
> c40 INTEGER,
> c41 NUMBER(1) DEFAULT 0 NOT NULL,
> c42 NVARCHAR2(2000),
> c43 NVARCHAR2(2000),
> c44 NVARCHAR2(255),
> c45 NVARCHAR2(2000),
> c46 NUMBER(1) DEFAULT 0 NOT NULL,
> c47 NCLOB,
> c48 NCLOB,
> c49 NVARCHAR2(255),
> c50 NCLOB,
> c51 NUMBER(38),
> c52 NUMBER(38),
> c53 NUMBER(38),
> c54 DATE,
> c55 INTEGER,
> c56 INTEGER,
> c57 NCLOB,
> c58 NCLOB,
> c59 NVARCHAR2(255),
> c60 NVARCHAR2(255),
> c61 INTEGER,
> c62 INTEGER,
> c63 INTEGER,
> c64 NUMBER(1) DEFAULT 0 NOT NULL,
> c65 NCLOB,
> c66 NCLOB,
> c67 NCLOB,
> c68 NCLOB
> );
--
//www.freelists.org/webpage/oracle-l
Other related posts:
