Re: Oracle Compress Option
Not at all, Chris - here you go. Chris Stephens wrote: Hey Mogens... Would you mind sending me a copy of that paper? Thanks either way!! chris -Original Message- Sent: Wednesday, September 24, 2003 9: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 [EMAIL PROTECTED] 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 DISCLAIMER: This message is intended for the sole use of the individual to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.vhttp://www.ukoug.org/calendar/jan03/jan30ab.htm Julian Dyke DataSegmentCompression.zip Description: Zip compressed data
RE: Oracle Compress Option
Title: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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 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.*2
RE: Oracle Compress Option
Title: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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
RE: Oracle Compress Option
Title: Message I agree: disk is cheap, as long as I don't have to pay for it. --Mladen GogalaOracle DBA -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jamadagni, RajendraSent: Thursday, September 25, 2003 9:50 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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 Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error,please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.Wang Trading LLCand any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
Re: Oracle Compress Option
Title: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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
RE: Oracle Compress Option
Title: RE: Oracle Compress Option Something else I forgot, full segment scans becomes faster, since he segment is 70 percent smaller. So this could help balancing resource utilization between the CPUs and IO. Waleed -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:50 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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
Re: Oracle Compress Option
Title: RE: Oracle Compress Option Hi! I think in DW style environments, compressed fact tables and indexes on them can give more benefit than just saved disk storage - if you save 50% in space due compression, then 100% more data can be read in single IO as well. Tanel. - Original Message - From: Khedr, Waleed To: Multiple recipients of list ORACLE-L Sent: Thursday, September 25, 2003 4:34 PM 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] 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
RE: Oracle Compress Option
Title: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 10:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]] 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 compress
Re: Oracle Compress Option
Title: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 10:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:05 AMTo: Multiple recipients of list ORACLE-LSubject: 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
RE: Oracle Compress Option
Title: 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 11:50 AMTo: Multiple recipients of list ORACLE-LSubject: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 10:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 9:35 AMTo: Multiple recipients of list ORACLE-LSubject: 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
Re: Oracle Compress Option
Raj, How can we know if only one Pvt Interconnect is used at a given time? How are you monitoring them real-time? Is the GC traffic not load balanced ? Are you using cluster_interconnects? Thanks, Ravi. - Original Message - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED] 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED
RE: Oracle Compress Option
Title: RE: Oracle Compress Option we monitor it through nmon ... (aix utility). GC traffic is not load balanced across both interconnects if that is what you mean. There is no way ... first one is used and if that fails the second is used. We are NOT using cluster interconnects I saw some bug reports ... on Metalink. 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: Ravi Kulkarni [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 25, 2003 12:15 PM To: Multiple recipients of list ORACLE-L Subject: Re: Oracle Compress Option Raj, How can we know if only one Pvt Interconnect is used at a given time? How are you monitoring them real-time? Is the GC traffic not load balanced ? Are you using cluster_interconnects? Thanks, Ravi. 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
Re: Oracle Compress Option
Raj, How can we know if only one Pvt Interconnect is used at a given time? How are you monitoring them real-time? Is the GC traffic not load balanced ? Are you using cluster_interconnects? Thanks, Ravi. - Original Message - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED] 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 - From: Jamadagni, Rajendra To: Multiple recipients of list ORACLE-L 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED
RE: Oracle Compress Option
Title: Message On our appliance, to get around the irritating load-balancing+failover issue, we're using 802.3ad link aggregation. Trying to load-balance Gigabit is really an exercise in futility - almost all of theperformance improvement comes from improved interrupt queuing (and even that is already mitigated on the cardthrough coalescing interrupts). The real benefit is the failover - that works very very well. Thanks, Matt --Matthew ZitoGridApp SystemsEmail: [EMAIL PROTECTED]Cell: 646-220-3551Phone: 212-358-8211 x 359http://www.gridapp.com -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jamadagni, RajendraSent: Thursday, September 25, 2003 12:45 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Oracle Compress Option we monitor it through nmon ... (aix utility). GC traffic is not load balanced across both interconnects if that is what you mean. There is no way ... first one is used and if that fails the second is used. We are NOT using cluster interconnects I saw some bug reports ... on Metalink. 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: Ravi Kulkarni [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 25, 2003 12:15 PM To: Multiple recipients of list ORACLE-L Subject: Re: Oracle Compress Option Raj, How can we know if only one Pvt Interconnect is used at a given time? How are you monitoring them real-time? Is the GC traffic not load balanced ? Are you using cluster_interconnects? Thanks, Ravi.
RE: Oracle Compress Option
Title: Message Matt, What is 802.3ad link aggregation ?? Any handy URLs ?? TIA 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: Matthew Zito [mailto:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 1:25 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Oracle Compress Option On our appliance, to get around the irritating load-balancing+failover issue, we're using 802.3ad link aggregation. Trying to load-balance Gigabit is really an exercise in futility - almost all of theperformance improvement comes from improved interrupt queuing (and even that is already mitigated on the cardthrough coalescing interrupts). The real benefit is the failover - that works very very well. Thanks, Matt 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
RE: Oracle Compress Option
Title: Message mucho gracias ... 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: Matthew Zito [mailto:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 3:20 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Oracle Compress Option What is 802.3ad link aggregation? Tell you what - buy the box and I'll tell ya how it works ;) Seriously, though, its a networking protocol for ethernet cards and ethernet switches to be aware of flow relationships - i.e. it makes the switches and hosts aware that the ethernet card attached to port 1 and the one attached to port 5 are actually part of the same node. So, nodes become aware of how to redirect traffic in case of a failure, as well as how to load balance AIX, right? Here's a link to IBM's discussion on it for the p-series: http://publib16.boulder.ibm.com/pseries/en_US/aixbman/commadmn/tcp_etherchannel.htm Good luck, Matt --Matthew ZitoGridApp SystemsEmail: [EMAIL PROTECTED]Cell: 646-220-3551Phone: 212-358-8211 x 359http://www.gridapp.com -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jamadagni, RajendraSent: Thursday, September 25, 2003 2:40 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Oracle Compress Option Matt, What is 802.3ad link aggregation ?? Any handy URLs ?? TIA 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: Matthew Zito [mailto:[EMAIL PROTECTED]Sent: Thursday, September 25, 2003 1:25 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Oracle Compress Option On our appliance, to get around the irritating load-balancing+failover issue, we're using 802.3ad link aggregation. Trying to load-balance Gigabit is really an exercise in futility - almost all of theperformance improvement comes from improved interrupt queuing (and even that is already mitigated on the cardthrough coalescing interrupts). The real benefit is the failover - that works very very well. Thanks, Matt 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.*2
RE: Oracle Compress Option
IF it is not too much trouble, could you e-mail me a copy of the article Mogens? Thank you. Reginald W. Bailey IBM Global Services - ETS SW GDSD - Database Management Your Friendly Neighborhood DBA 713-216-7703 (Office) 281-798-5474 (Mobile) 713-415-5410 (Pager) [EMAIL PROTECTED] [EMAIL PROTECTED] ChrisStephens@ affina.com To: [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED] Subject: RE: Oracle Compress Option ity.com 09/25/2003 03:54 PM Please respond to ORACLE-L Hey Mogens... Would you mind sending me a copy of that paper? Thanks either way!! chris -Original Message- Sent: Wednesday, September 24, 2003 9: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 [EMAIL PROTECTED] 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 DISCLAIMER: This message is intended for the sole use of the individual to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.vhttp://www.ukoug.org/calendar/jan03/jan30ab.htm -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Chris Stephens INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include
RE: Oracle Compress Option
Yes please, my email id is [EMAIL PROTECTED] -Original Message- Sent: Wednesday, September 24, 2003 7: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 [EMAIL PROTECTED] 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 DISCLAIMER: This message is intended for the sole use of the individual to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.vhttp://www.ukoug.org/calendar/jan03/jan30ab.htm -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). DISCLAIMER: This message is intended for the sole use of the individual to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
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 [EMAIL PROTECTED] 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 DISCLAIMER: This message is intended for the sole use of the individual to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.vhttp://www.ukoug.org/calendar/jan03/jan30ab.htm -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
