Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h8PJxiQ23915 for ; Thu, 25 Sep 2003 14:59:44 -0500 X-ClientAddr: 66.27.56.212 Received: from www3.fatcity.com (rrcs-west-66-27-56-212.biz.rr.com [66.27.56.212]) by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h8PJxic23910 for ; Thu, 25 Sep 2003 14:59:44 -0500 Received: (from root@localhost) by www3.fatcity.com (8.11.6/8.11.6) id h8PEoZ027592 for oracle-l@orafaq.net; Thu, 25 Sep 2003 07:50:35 -0700 Received: by fatcity.com (05-Jun-2003/v1.0g-b73/bab) via fatcity.com id 005D10D0; Thu, 25 Sep 2003 07:49:43 -0800 Message-ID: Date: Thu, 25 Sep 2003 07:49:43 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: "Tanel Poder" Sender: ml-errors@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: "Tanel Poder" Subject: Re: Oracle Compress Option Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 73; ListGuru (c) 1996-2003 Bruce A. Bergman Precedence: bulk Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1403_01C3838C.F9358440" ------=_NextPart_000_1403_01C3838C.F9358440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Oracle Compress OptionThanks for the information. One more question, is your interconnect ethernet based or proprietary = such hyperfabric for hp etc.. Thanks, Tanel. ----- Original Message -----=20 From: Jamadagni, Rajendra=20 To: Multiple recipients of list ORACLE-L=20 Sent: Thursday, September 25, 2003 6:19 PM Subject: RE: Oracle Compress Option we have 2 gbit private interconnects of which only one is used at any = given time. Everyone else talks to the dbs using public network. Both = are active/active. On one instance luckily we have application = partitioning one side manages the feeds that come from every = foot/bast/basketball, hockey and scores of other games and processes = them and sends it out to customers. Another side takes this data plus = people sitting to make corrections if any before it is fed to video = generators and goes on espn network broadcast. So it works fine. Other instances are legacy ... the active/active is more like a HA = configuration, lots of people connected on either side all the time lots = of DML activity going around all the time. We see more of a GC traffic = ... but we are experimenting with _fairness_threshold parameter to see = if that will help. As for performance issues, we encounter lots of BBW = but unfortunately that is due to business logic and can't be easily = changed. Otherwise we do fine. Raj = -------------------------------------------------------------------------= -------=20 Rajendra dot Jamadagni at nospamespn dot com=20 All Views expressed in this email are strictly personal.=20 QOTD: Any clod can have facts, having an opinion is an art !=20 -----Original Message----- From: Tanel Poder [mailto:tanel.poder.003@mail.ee] Sent: Thursday, September 25, 2003 10:35 AM To: Multiple recipients of list ORACLE-L Subject: Re: Oracle Compress Option Hm, interesting... How does your active-active config work, do you have write activity = on all nodes? I'd be interested in any performance issues you had or currently = have... Have you partitioned your application or data usage somehow? What kind of interconnect you're using? Tanel. ----- Original Message -----=20 From: Jamadagni, Rajendra=20 To: Multiple recipients of list ORACLE-L=20 Sent: Thursday, September 25, 2003 4:49 PM Subject: RE: Oracle Compress Option Waleed, I get your point ...=20 We have 6 RAC instances that run active-active ... and compared to = availability requirements, we (incl management) decided that disk is = cheap. I guess it is relative ... Raj = -------------------------------------------------------------------------= -------=20 Rajendra dot Jamadagni at nospamespn dot com=20 All Views expressed in this email are strictly personal.=20 QOTD: Any clod can have facts, having an opinion is an art !=20 -----Original Message----- From: Khedr, Waleed [mailto:Waleed.Khedr@FMR.COM] Sent: Thursday, September 25, 2003 9:35 AM To: Multiple recipients of list ORACLE-L Subject: RE: Oracle Compress Option Disk is not cheap if you pay for high availability = configuration. I compress historical data on daily basis and was able to = save 70 percent of the disk space. Imagine the amount of savings for = five TB. Two major issues: 1) Oracle says updates will be slow on compressed tables, but I = say don't even try to update a compressed table, uncompress first = otherwise you will end up with a segment that is not good at all for = scattered reads. 2) You can not add columns to the table when it's compressed, so = if you compressed a big table and need a new column you need to recreate = the table without compression. So adding many extra columns before = compression is a good idea. It's mainly good for data warehouses applications. Regards, Waleed -----Original Message----- From: Jamadagni, Rajendra [mailto:Rajendra.Jamadagni@espn.com] Sent: Thursday, September 25, 2003 9:05 AM To: Multiple recipients of list ORACLE-L Subject: RE: Oracle Compress Option I think 9202 doesn't like to export compressed tables in = direct mode ... so watch out for that ... I implemented, tested and next = day reverted back to regular tables due to this export issue. Disk is = cheap. A BAARF party member wannabe !!=20 Raj=20 = -------------------------------------------------------------------------= -------=20 Rajendra dot Jamadagni at nospamespn dot com=20 All Views expressed in this email are strictly personal.=20 QOTD: Any clod can have facts, having an opinion is an art !=20 -----Original Message-----=20 From: Mogens N=F8rgaard [mailto:mln@miracleas.dk]=20 Sent: Wednesday, September 24, 2003 10:05 PM=20 To: Multiple recipients of list ORACLE-L=20 Subject: Re: Oracle Compress Option=20 "Compress to impress?" by Julian Dyke is a good presentation = on this=20 topic (see for instance = http://www.ukoug.org/calendar/jan03/jan30ab.htm).=20 I do have the article - 202 K with no compression, 147 K with=20 compression :).=20 Let me know if you're interested, and I'll email it directly = to you.=20 Mogens=20 Avnish.Rastogi@providence.org wrote:=20 >Does anybody has any experience with Oracle 9I compression = option. I did some test on 9202 with a table of more 14 million rows. = Table has total 7 indexes. Surprising both table and indexes are using = more space after compression. Before compression space used is 13064MB = and after compression 13184MB. In both the cases I did export from = source table and stored in two different tablespaces. Any insight on = that and any disadvantages of using that. >=20 >Thanks=20 ------=_NextPart_000_1403_01C3838C.F9358440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Oracle Compress Option
Thanks for the = information.
 
One more question, is your interconnect = ethernet=20 based or proprietary such hyperfabric for hp etc..
 
Thanks,
Tanel.
----- Original Message -----
From:=20 Jamadagni, Rajendra =
Sent: Thursday, September 25, = 2003 6:19=20 PM
Subject: RE: Oracle Compress = Option

we have 2 gbit private interconnects of which only one is = used at any=20 given time. Everyone else talks to the dbs using public network. Both = are=20 active/active. On one instance luckily we have application = partitioning one=20 side manages the feeds that come from every foot/bast/basketball, = hockey and=20 scores of other games and processes them and sends it out to = customers.=20 Another side takes this data plus people sitting to make corrections = if any=20 before it is fed to video generators and goes on espn network = broadcast. So it=20 works fine.
 
Other instances are legacy ... the active/active is more like = a HA=20 configuration, lots of people connected on either side all the time = lots of=20 DML activity going around all the time. We see more of a GC traffic = ... but we=20 are experimenting with _fairness_threshold parameter to see if that = will help.=20 As for performance issues, we encounter lots of BBW but unfortunately = that is=20 due to business logic and can't be easily changed.
 
Otherwise we do fine.
Raj
----------------------------------------------------------------= ----------------=20
Rajendra dot Jamadagni at = nospamespn dot=20 com
All Views expressed = in this=20 email are strictly personal.
QOTD:=20 Any clod can have facts, having an opinion is an art !
-----Original Message-----
From: Tanel Poder=20 [mailto:tanel.poder.003@mail.ee]
Sent: Thursday, September = 25,=20 2003 10:35 AM
To: Multiple recipients of list=20 ORACLE-L
Subject: Re: Oracle Compress = Option

Hm, interesting...
 
How does your active-active config = work, do you=20 have write activity on all nodes?
I'd be interested in any = performance issues you=20 had or currently have...
Have you partitioned your = application or data=20 usage somehow?
What kind of interconnect you're=20 using?
 
Tanel.
----- Original Message ----- =
From:=20 Jamadagni, = Rajendra
Sent: Thursday, September = 25, 2003=20 4:49 PM
Subject: RE: Oracle = Compress=20 Option

Waleed, I get your point ...
 
We have 6 RAC instances that run active-active ... and = compared to=20 availability requirements, we (incl management) decided that disk = is=20 cheap.
 
I guess it is relative ...
 
Raj
----------------------------------------------------------------= ----------------=20
Rajendra dot Jamadagni at = nospamespn=20 dot com
All Views = expressed in=20 this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an = art !=20
-----Original Message-----
From: Khedr, = Waleed=20 [mailto:Waleed.Khedr@FMR.COM]
Sent: Thursday, = September 25,=20 2003 9:35 AM
To: Multiple recipients of list=20 ORACLE-L
Subject: RE: Oracle Compress=20 Option

Disk is=20 not cheap if you pay for high availability configuration. I = compress=20 historical data on daily basis and was able to save 70 percent = of the=20 disk space. Imagine the amount of savings for five=20 TB.
 
Two major=20 issues:
 
1) Oracle=20 says updates will be slow on compressed tables, but I say don't = even try=20 to update a compressed table, uncompress first otherwise you = will end up=20 with a segment that is not good at all for scattered=20 reads.
 
2) You=20 can not add columns to the table when it's compressed, so if you = compressed a big table and need a new column you need to = recreate the=20 table without compression. So adding many extra columns before=20 compression is a good idea.
 
It's=20 mainly good for data warehouses = applications.
 
Regards,
 
Waleed
 
-----Original Message-----
From: Jamadagni, = Rajendra=20 [mailto:Rajendra.Jamadagni@espn.com]
Sent: Thursday, = September 25, 2003 9:05 AM
To: Multiple recipients = of list=20 ORACLE-L
Subject: RE: Oracle Compress=20 Option

I think 9202 doesn't like to export = compressed tables=20 in direct mode ... so watch out for that ... I implemented, = tested and=20 next day reverted back to regular tables due to this export = issue.=20 Disk is cheap.

A BAARF party member wannabe !! =
Raj
----------------------------------------------------------------= ----------------=20
Rajendra dot Jamadagni at nospamespn dot = com=20
All Views expressed in this email are = strictly=20 personal.
QOTD: Any clod can have = facts,=20 having an opinion is an art !


-----Original Message-----
From: Mogens N=F8rgaard [mailto:mln@miracleas.dk]=20
Sent: Wednesday, September 24, 2003 10:05 = PM=20
To: Multiple recipients of list = ORACLE-L=20
Subject: Re: Oracle Compress Option =


"Compress to impress?" by Julian Dyke is a = good=20 presentation on this
topic (see for = instance=20 http://www.ukoug.org/calendar/jan03/jan30ab.htm).=20

I do have the article - 202 K with no = compression, 147=20 K with
compression :).

Let me know if you're interested, and I'll = email it=20 directly to you.

Mogens

Avnish.Rastogi@providence.org wrote: =

>Does anybody has any experience with = Oracle 9I=20 compression option. I did some test on 9202 with a table of = more 14=20 million rows. Table has total 7 indexes. Surprising both table = and=20 indexes are using more space after compression. Before = compression=20 space used is 13064MB and after compression 13184MB. In both = the cases=20 I did export from source table and stored in two different=20 tablespaces. Any insight on that and any disadvantages of = using=20 that.

>
>Thanks=20 =

------=_NextPart_000_1403_01C3838C.F9358440-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder INET: tanel.poder.003@mail.ee Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).