Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h8PIbQb19039 for ; Thu, 25 Sep 2003 13:37:27 -0500 X-ClientAddr: 66.27.56.213 Received: from www2.fatcity.com (rrcs-west-66-27-56-213.biz.rr.com [66.27.56.213]) by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h8PIbQc19031 for ; Thu, 25 Sep 2003 13:37:26 -0500 Received: (from root@localhost) by www2.fatcity.com (8.11.6/8.11.6) id h8PF8c322224 for oracle-l@orafaq.net; Thu, 25 Sep 2003 08:08:38 -0700 Received: by fatcity.com (05-Jun-2003/v1.0g-b73/bab) via fatcity.com id 005D10D8; Thu, 25 Sep 2003 08:04:55 -0800 Message-ID: Date: Thu, 25 Sep 2003 08:04:55 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: "Jamadagni, Rajendra" Sender: ml-errors@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: "Jamadagni, Rajendra" 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/mixed; boundary="----=_NextPartTM-000-5dc8eb94-70b6-4313-b4d0-00ea59cd5f64" ------=_NextPartTM-000-5dc8eb94-70b6-4313-b4d0-00ea59cd5f64 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38376.09CD37DC" ------_=_NextPart_001_01C38376.09CD37DC Content-Type: text/plain; charset="iso-8859-1" ethernet ... gBit ... Raj ---------------------------------------------------------------------------- ---- Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message----- Sent: Thursday, September 25, 2003 11:50 AM To: Multiple recipients of list ORACLE-L Thanks for the information. One more question, is your interconnect ethernet based or proprietary such hyperfabric for hp etc.. Thanks, Tanel. ----- Original Message ----- To: Multiple recipients of list ORACLE-L Sent: Thursday, September 25, 2003 6:19 PM 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 ---------------------------------------------------------------------------- ---- Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message----- Sent: Thursday, September 25, 2003 10:35 AM To: Multiple recipients of list ORACLE-L 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 ----- To: Multiple recipients of list ORACLE-L Sent: Thursday, September 25, 2003 4:49 PM Waleed, I get your point ... 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 ---------------------------------------------------------------------------- ---- Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message----- Sent: Thursday, September 25, 2003 9:35 AM To: Multiple recipients of list ORACLE-L 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----- Sent: Thursday, September 25, 2003 9:05 AM To: Multiple recipients of list ORACLE-L 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 !! Raj ---------------------------------------------------------------------------- ---- Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message----- Sent: Wednesday, September 24, 2003 10:05 PM To: Multiple recipients of list ORACLE-L "Compress to impress?" by Julian Dyke is a good presentation on this topic (see for instance http://www.ukoug.org/calendar/jan03/jan30ab.htm ). I do have the article - 202 K with no compression, 147 K with compression :). Let me know if you're interested, and I'll email it directly to you. Mogens Avnish.Rastogi@providence.org wrote: >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. > >Thanks ------_=_NextPart_001_01C38376.09CD37DC Content-Type: text/html; charset="iso-8859-1" RE: Oracle Compress Option
ethernet ... gBit ...
 
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----Original Message-----
From: Tanel Poder [mailto:tanel.poder.003@mail.ee]
Sent: Thursday, September 25, 2003 11:50 AM
To: Multiple recipients of list ORACLE-L
Subject: Re: Oracle Compress Option

Thanks for the information.
 
One more question, is your interconnect ethernet based or proprietary such hyperfabric for hp etc..
 
Thanks,
Tanel.
----- Original Message -----
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
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----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 -----
Sent: Thursday, September 25, 2003 4:49 PM
Subject: RE: Oracle Compress Option

Waleed, I get your point ...
 
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
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----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 !!
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


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


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

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

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

Mogens

Avnish.Rastogi@providence.org wrote:

>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.

>
>Thanks

------_=_NextPart_001_01C38376.09CD37DC-- ------=_NextPartTM-000-5dc8eb94-70b6-4313-b4d0-00ea59cd5f64 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************1 ------=_NextPartTM-000-5dc8eb94-70b6-4313-b4d0-00ea59cd5f64-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jamadagni, Rajendra INET: Rajendra.Jamadagni@espn.com 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).