Archive for the ‘Oracle 11g’ Category
Index Dynamics – Part 3
Filed under: Innerworkings, Maintenance, Oracle 10g, Oracle 11g, Oracle 9i | Tags: LinkedIn
Comments (1) 
See previous post Index Dynamics – Part II or first part Index Dynamics – Part I
On this part, I’m going to share with you the final results for my 2 week experiment with indexes on their habitat, a production environment.
I’ve to forewarn that some data was not available, as the ANALYZE method fails for objects currently locked, given that our environment is a “live” production database and for consistency we scheduled all tests for a given time, which some days collided with business process. The Used Space graph shows those NA data points; however for INDEX1 and INDEX4 the Nov 7th data for Deltas was interpolated, the only index for which we have all samples is INDEX2, coincidentally our research subject.
First let’s see the Used Space graph, here you may see how the Used Space percentage continues the decay trend, which means that free space within the index nodes is increasing.
Compare the current Used Space figures to those sampled before the rebuild, observe that after 15 days some indexes are midway to have the same amount of free space. That recalls the frequent doubts regarding index maintenance: “Must rebuild indexes? How long will last the structure ‘optimus’ state?”
Used Space First Now INDEX1(10c) 69% 99% INDEX4(6c) 63% 74% INDEX2(4c) 53% 77% INDEX3(2c) 45% 92%
Given our partial-conclusion stated last post (Index Dynamics – Part II)
”The branch blocks are the stressed part of the B-Tree right after the rebuild”
We now might see less activity for Branch Blocks during the following days, which actually occurred.
One remark: observe the Nov 6th high for INDEX1 and the previous behavior, was on that day the transaction rate motivated a higher reorganization within the index, showing us the impact business patterns have on data structures.
I have to mention that my production environment went through a period close week, therefore increased activity and closing processes made their mark on observations. An example of this is the resulting graphs for Leaf Blocks, with noticeable inter-day spikes.
Let’s pay a visit to our research subject, INDEX2. This chart is online with everything previously stated, no surprises here.
This study motivated the following questions (that’s the problem with research, you answer one question and many new take the place):
1) How PCT_FREE (or PCT_USED) impacts the decay curve?
2) Are the splitting constants embedded in the code, optimal figures?
3) Do we need a feature for PCT_FREE change after rebuild has been done?
Conclusions
* High stress within the branch blocks may be observed as soon as transactions start to modify the index structure; the stress period or intensity, will depend on transaction rate and index attributes.
Recommendation
* Do not rebuild indexes right before processes or high load days, if heavy writing is expected: the index leaf block split overhead may impact performance.
I’ve the pending assignment of proposing a mathematical model for the Index Decay Rate… I’m working on that, with the help of Calculus. My next delivery will talk about that, I’m pretty close…
Thank you for reading, don’t forget to leave your comments.
See previous post Index Dynamics – Part II or first part Index Dynamics – Part I
Index Dynamics – Part 2 (Halloween on the Block)
Filed under: Innerworkings, Maintenance, Oracle 10g, Oracle 11g, Oracle 9i | Tags: LinkedIn
Comments (1)
View starting post: Index Dynamics – Part 1
As I’ve promised, today will share with you mid-term results for my index observations.
First we may see a graph of Used Space, as reported by column PCT_USED of table INDEX_STATS (right after an ANALYZE over each index). This percentage accounts the space allocated to the B-Tree that is used.
There is one line for every index we are considering, and note the legend on the graph showing the index name and the number of columns inside parenthesis.
What can be observed in this chart?
1) After rebuild (done on saturday), every index starts with 95% used space.
2) First day is sunday, the system had almost 0 activity, therefore our indexes’ space usage show slight changes.
3) Starting on monday, INDEX1 reported wrong data for PCT_USED and the other indexes began their “decay” trend.
4) After a whole week of activity, indexes gained free space, some of them faster than others (for instance INDEX4 went from 95% to 84% used space, that is 11% on 5 days).
Point 3 raised a service request with Oracle.
Point 4 may be explained in terms of:
a) Table transactionality (how many insertions/deletes/updates it had)
b) Index type, if unique or non-unique.
c) Number of columns conforming the index.
d) Type of every indexed column.
I may propose the following hypothesis: the index used space decay rate is directly proportional to the table’s transactionality, to the number of columns and types of them, and inversely proportional to the type of the index (Unique or non-Unique) and block size.
As you already know, B-Tree indexes have two types of nodes: called Branches and Leafs.
Now, let’s see where is that space allocated, look this chart that shows increment or delta on daily samples taken from column LF_BLKS.
You may see a great saving due to rebuild, however that saving fades slowly during the following days. Next chart makes a zoom, in order to watch closely the variation rate experimented during those days.
Keep in mind the rate at which leaf blocks are incremented, later you’ll see how it’s related to new key insertions (transactionality).
What about the branches? … that’s what we’re going to see on next chart: the behavior of those indexes for branch blocks. I’ve taken the sampled value for BR_BLKS and got the variation rate versus the previous day.
Please observe, the stepped peak for INDEX2 and INDEX4, during the first day of activity the number of branch blocks almost doubled, that means an intense reorganization within the index. That may be caused due to the nature of these indexes (all are UNIQUE) and a high transactionality rate.
For the INDEX3, we observe that the increase is splited between 2 days, Sunday and Monday. This table presented activity the day after the rebuild was done.
We have to ignore the INDEX4, cause their figures are not reliable.
Why is there a higher increase on the number of branch blocks? We may answer that question recalling the percentage of free space (5%) we had after the rebuild, that is a very small margin for a leaf block, and the chances of split increase if we have a UNIQUE index. We must remember that a leaf block split, may involve a branch block split.
Our partial conclusions may be stated as follow:
1) Depending on the percentage of free space, after rebuilding indexes, their state becomes “less” stable.
2) Indexes tend to take a “stable” form, with the pass of time.
3) The branch blocks are the stressed part of the B-Tree right after the rebuild.
I will finish this experiment next Saturday, and share with you all remaining findings next Tuesday; yes, seven days from now… or eight days? anyway…
I hope to get near a mathematical model for the Index Decay Rate, cross fingers.
Thank you for reading, keep in touch!
See next part on Index Dynamics – Part III or go to first part Index Dynamics – Part I
How to Flush your database caches
Filed under: Maintenance, Oracle 10g, Oracle 11g, Oracle 9i, Tricks |
Leave a Comment
Flushing the SGA memory areas, Shared Pool and Buffer Cache, it’s an uncommon task, however, it gets useful when you’re doing some tests and want to override the memory and go direct to disk, or when you have shared pool issues (here is a workaround, however I encourage you to find the root cause).
Shared Pool flush
This is the only sentence you have to know for releases 9i and up…
alter system flush shared_pool
Buffer Cache flush
For Oracle 9i I didn’t know how to do this, fortunately found it today on Rahat Agivetova’s blog
alter session set events = 'immediate trace name flush_cache';
I’ve tested it and does the job well…
And for Oracle 10g and up, the syntaxis is as follows:
alter system flush buffer_cache;
But you already knew that, isn’t it? …well, this was a “snack” post until Friday’s follow up to Index Dynamics, which I may anticipate interesting results…
Thanks for reading… and for your comments, too!
Index dynamics
Filed under: Innerworkings, Maintenance, Oracle 10g, Oracle 11g, Oracle 9i | Tags: LinkedIn
Comments (1)
Today I will start with a series of 3 posts depicting the follow up of 4 index behavior on a Production database.
The purpose of this exercise is try to unveil the morphology these four indexes take during a given period of time, under what kind of load, model it in a graphical way. Since indexes are quite a black box, this exercises also proposes a complementary procedure for index quality measure.
Experiment subjects were selected using information on DBA_SEGMENTS+DBA_HIST_SEGMENTS, with focus on size and activity, indexes were choosen within the 400Mb-500Mb range thinking on fast ALTER INDEX REBUILD and fast ANALYZE VALIDATE STRUCTURE.
Our four candidates are (names were replaced in order to protect their identity)
OBJNAME BLOCKS BYTES HEIGHT PCTUSED -------------------- ---------- ---------- ------ ------- INDEX1 62464 511705088 4 69 INDEX2 60416 494927872 4 53 INDEX3 61056 500170752 4 45 INDEX4 54272 444596224 4 63
We have our “Before” snapshots, now we need to rebuild all four indexes and take “Initial” snapshots to start the experiment. After this operation our figures are:
OBJNAME BLOCKS BYTES HEIGHT PCT_USED -------------------- ---------- ---------- ------ -------- INDEX1 41600 340787200 4 95 INDEX2 34176 279969792 4 95 INDEX3 28032 229638144 3 95 INDEX4 37888 270445017 4 95
Note the amount of space “empty” the indexes had before rebuild, for INDEX2 and INDEX2 we may ask ourselves “How are the tables used in order to get index keys so dispersed?”. INDEX1 and INDEX4 seem within normal parameters. All four indexes now have the same initial condition on 5% free space.
On October 31th, Friday … Hallowen, we are going to see what has been happening with our indexes;and who knows, you may testify witchcraft… or, is it science? What do you think?
Keep in touch…
See next part of this story on Index Dynamics – Part II
Statspack snapshot levels
You’re going to start taking snapshots for Statspack reports, however do you really know what level will give you the detail you want? Valid values for snapshot level are 0,5,6,7 and 10, ordered from the less detailed to the most detailed.
Following are listed all the sections that may appear on a Statspack report and the snapshot level you need to run in order to get data for them. They are listed as their appearance order within the Statspack report. An ‘X’ mark means “present”.
| Snapshot Level | |||||
| 0 | 5 | 6 | 7 | 10 | |
| STATSPACK report for | x | x | x | x | x |
| Load Profile | x | x | x | x | x |
| Instance Efficiency Percentages | x | x | x | x | x |
| Top 5 Timed Events | x | x | x | x | x |
| Wait Events for DB | x | x | x | x | x |
| Background Wait Events for DB | x | x | x | x | x |
| SQL ordered by Gets for DB | x | x | x | x | |
| SQL ordered by Reads for DB | x | x | x | x | |
| SQL ordered by Executions for DB | x | x | x | x | |
| SQL ordered by Parse Calls for DB | x | x | x | x | |
| SQL ordered by Sharable Memory for DB | x | x | x | x | |
| Instance Activity Stats for DB | x | x | x | x | x |
| Tablespace IO Stats for DB | x | x | x | x | x |
| File IO Stats for DB | x | x | x | x | x |
| Buffer Pool Statistics for DB | x | x | x | x | x |
| Instance Recovery Stats for DB | x | x | x | x | x |
| Buffer Pool Advisory for DB | x | x | x | x | x |
| Buffer wait Statistics for DB | x | x | |||
| PGA Aggr Target Stats for DB | x | x | x | x | x |
| PGA Aggr Target Histogram for DB | x | x | x | x | x |
| PGA Memory Advisory for DB | x | x | x | x | x |
| Enqueue activity for DB | x | ||||
| Rollback Segment Stats for DB | x | x | x | x | x |
| Rollback Segment Storage for DB | x | x | x | x | x |
| Undo Segment Summary for DB | x | x | x | x | |
| Undo Segment Stats for DB | x | x | x | x | |
| Latch Activity for DB | x | x | x | x | x |
| Latch Sleep breakdown for DB | x | x | x | x | x |
| Latch Miss Sources for DB | x | x | x | x | x |
| Parent Latch Statistics DB | x | ||||
| Child Latch Statistics DB | x | ||||
| Top 5 Logical Reads per Segment for DB | x | x | |||
| Top 5 Physical Reads per Segment for DB | x | x | |||
| Top 5 Buf. Busy Waits per Segment for DB | x | x | |||
| Top 5 Row Lock Waits per Segment for DB | x | ||||
| Top 5 ITL Waits per Segment for DB | x | ||||
| Dictionary Cache Stats for DB | x | x | x | x | x |
| Library Cache Activity for DB | x | x | x | x | x |
| Shared Pool Advisory for DB | x | x | x | x | x |
| SGA Memory Summary for DB | x | x | x | x | x |
| SGA breakdown difference for DB | x | x | x | x | x |
| Resource Limit Stats for DB | x | x | x | x | x |
| init.ora Parameters for DB | x | x | x | x | x |
Real Application Testing backported to 10g and 9i
This functionality has been such a success that Oracle has decided to backport it to previous supported releases. That includes 9.2.0.8, 10.1.0.2 and up, 10.2.0.2 and up.
The easiest path is 10.2.0.4 because it includes the RAT functionality, any other option needs an additional patch in order to enable it.
Personally I consider Oracle has made a very smart move, this feature may wake upgrade desire everywhere and add one more reason to make the effort and upgrade to 10g… and who knows, even trigger a jump to 11g in some cases.
I need your vote for OracleOpenWorld!!!
Hi folks!!!
I’m planning to attend Oracle OpenWorld 2008 as a speaker, therefore I will appreciate your kind support for these proposals Capacity Planning with Oracle products in 1 day and 11g Advanced Compression unleashed.
I’m counting on your vote to get one of my proposals approved.
Thank you very much!
Sure…your trash will drag you!!!
In case you are lost in the darkness follow the next real-life case:
Connected to:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP and Data Mining options SQL> select count(*) from dba_free_space; COUNT(*)---------- 193822 _SQL> select count(*) from all_objects where object_name like '%BIN%'; COUNT(*)---------- 175249 SQL> set timing onSQL> run 1 select count(*) from all_objects where object_name like '%BIN%' 2* COUNT(*)---------- 175249 Elapsed: 00:00:27.00SQL> select count(*) from dba_free_space; COUNT(*)---------- 193821 Elapsed: 00:00:45.71
SQL> select num_rows, blocks from all_Tables where table_name = 'RECYCLEBIN$'; NUM_ROWS BLOCKS---------- ---------- 185640 2308 Elapsed: 00:00:00.05SQL> exec dbms_stats.gather_table_stats(ownname=> 'SYS',2: tabname=> 'RECYCLEBIN$', partname=> NULL); PL/SQL procedure successfully completed. Elapsed: 00:00:06.70SQL> select count(*) from dba_free_space; COUNT(*)---------- 193820 Elapsed: 00:00:46.02SQL> run 1* select count(*) from dba_free_space COUNT(*)---------- 193787 Elapsed: 00:00:45.82SQL> set autotrace on explain statisticsSQL> run 1* select count(*) from dba_free_space COUNT(*)---------- 193787 Elapsed: 00:00:46.20 Execution Plan---------------------------------------------------------- ------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | | | 1563 (53)|| 1 | SORT AGGREGATE | | 1 | | | || 2 | VIEW | DBA_FREE_SPACE | 190 | | | 1563 (53)|| 3 | UNION-ALL | | | | | || 4 | NESTED LOOPS | | 1 | 39 | | 4 (0)|| 5 | NESTED LOOPS | | 1 | 32 | | 3 (0)|| 6 | TABLE ACCESS FULL | FET$ | 1 | 26 | | 3 (0)|| 7 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 8 | TABLE ACCESS CLUSTER | TS$ | 1 | 7 | | 1 (0)|| 9 | NESTED LOOPS | | 90 | 4050 | | 12 (9)|| 10 | NESTED LOOPS | | 90 | 3510 | | 12 (9)|| 11 | TABLE ACCESS FULL | TS$ | 36 | 468 | | 11 (0)|| 12 | FIXED TABLE FIXED INDEX | X$KTFBFE (ind:1) | 3 | 78 | | 0 (0)|| 13 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 14 | NESTED LOOPS | | 98 | 6762 | | 1530 (54)|| 15 | NESTED LOOPS | | 98 | 6174 | | 1530 (54)|| 16 | HASH JOIN | | 169K| 3983K| 3920K| 840 (16)|| 17 | TABLE ACCESS FULL | RECYCLEBIN$ | 174K| 1871K| | 585 (14)|| 18 | TABLE ACCESS FULL | TS$ | 36 | 468 | | 11 (0)|| 19 | FIXED TABLE FIXED INDEX | X$KTFBUE (ind:1) | 1 | 39 | | 0 (0)|| 20 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 21 | TABLE ACCESS BY INDEX ROWID| RECYCLEBIN$ | 1 | 11 | | 2 (0)|| 22 | NESTED LOOPS | | 1 | 63 | | 17 (0)|| 23 | NESTED LOOPS | | 1 | 52 | | 15 (0)|| 24 | NESTED LOOPS | | 1 | 45 | | 14 (0)|| 25 | TABLE ACCESS FULL | UET$ | 1 | 39 | | 14 (0)|| 26 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 27 | TABLE ACCESS CLUSTER | TS$ | 1 | 7 | | 1 (0)|| 28 | INDEX UNIQUE SCAN | I_TS# | 1 | | | 0 (0)|| 29 | INDEX RANGE SCAN | RECYCLEBIN$_TS | 7961 | | | 2 (0)|------------------------------------------------------------------------------------------------ Statistics---------------------------------------------------------- 4027917 recursive calls 129 db block gets 891718 consistent gets 175114 physical reads 0 redo size 517 bytes sent via SQL*Net to client 469 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> set autotrace off
SQL> purge dbarecycle_bin; Recyclebin purged
SQL> run 1* select count(*) from all_objects where object_name like '%BIN%' COUNT(*)---------- 103 Elapsed: 00:00:00.20 SQL> set linesize 255SQL> set autotrace on explain statisticsSQL> run 1* select count(*) from dba_free_space COUNT(*)---------- 1140 Elapsed: 00:00:00.06 Execution Plan---------------------------------------------------------- ------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | | | 1563 (53)|| 1 | SORT AGGREGATE | | 1 | | | || 2 | VIEW | DBA_FREE_SPACE | 190 | | | 1563 (53)|| 3 | UNION-ALL | | | | | || 4 | NESTED LOOPS | | 1 | 39 | | 4 (0)|| 5 | NESTED LOOPS | | 1 | 32 | | 3 (0)|| 6 | TABLE ACCESS FULL | FET$ | 1 | 26 | | 3 (0)|| 7 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 8 | TABLE ACCESS CLUSTER | TS$ | 1 | 7 | | 1 (0)|| 9 | NESTED LOOPS | | 90 | 4050 | | 12 (9)|| 10 | NESTED LOOPS | | 90 | 3510 | | 12 (9)|| 11 | TABLE ACCESS FULL | TS$ | 36 | 468 | | 11 (0)|| 12 | FIXED TABLE FIXED INDEX | X$KTFBFE (ind:1) | 3 | 78 | | 0 (0)|| 13 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 14 | NESTED LOOPS | | 98 | 6762 | | 1530 (54)|| 15 | NESTED LOOPS | | 98 | 6174 | | 1530 (54)|| 16 | HASH JOIN | | 169K| 3983K| 3920K| 840 (16)|| 17 | TABLE ACCESS FULL | RECYCLEBIN$ | 174K| 1871K| | 585 (14)|| 18 | TABLE ACCESS FULL | TS$ | 36 | 468 | | 11 (0)|| 19 | FIXED TABLE FIXED INDEX | X$KTFBUE (ind:1) | 1 | 39 | | 0 (0)|| 20 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 21 | TABLE ACCESS BY INDEX ROWID| RECYCLEBIN$ | 1 | 11 | | 2 (0)|| 22 | NESTED LOOPS | | 1 | 63 | | 17 (0)|| 23 | NESTED LOOPS | | 1 | 52 | | 15 (0)|| 24 | NESTED LOOPS | | 1 | 45 | | 14 (0)|| 25 | TABLE ACCESS FULL | UET$ | 1 | 39 | | 14 (0)|| 26 | INDEX UNIQUE SCAN | I_FILE2 | 1 | 6 | | 0 (0)|| 27 | TABLE ACCESS CLUSTER | TS$ | 1 | 7 | | 1 (0)|| 28 | INDEX UNIQUE SCAN | I_TS# | 1 | | | 0 (0)|| 29 | INDEX RANGE SCAN | RECYCLEBIN$_TS | 7961 | | | 2 (0)|------------------------------------------------------------------------------------------------ Statistics---------------------------------------------------------- 295 recursive calls 129 db block gets 12437 consistent gets 0 physical reads 0 redo size 516 bytes sent via SQL*Net to client 469 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed
Please, before you go, don’t forget to vote the poll regarding the content of this blog, thank you!
Poor’s man Capacity Planning
On the other side, the IT operation is facing an explosive growth of business requirements and information flow that most of the time lends to insufficient resources, even if we planned ahead.
ITIL’s Capacity planning intend to cover the broad range of IT operations, from document printing requests to server renovation or upgrade. I’ll focus on ideas related to Database Capacity planning and related resources.
The Avalanche is here!
Yes, data growth is a headache and if you don’t take actions in advance, you’ll be buried by your data. Fortunately for us, this doesn’t happen overnight and growth follows a pattern that will help you to forecast purchase of additional storage… or an eventual failure if nothing is done.
First you need to start collecting data for every one of your databases, consolidation of results may depend on your storage architecture, server assignation, business area or the grouping criteria of your choice.
This is very simple, you’ll need to query the tablespace free and total space and store it in a table . If you have more than one database, its better to centralize information sending results to a repository. With oracle that is pretty straightforward: you’ll need cron, sql*plus and sql*loader, just that.
The repository DB must be added to the local tnsnames.ora file, because sqlldr will access the repository using the username/password@database login form. You will need a table to store DB Name, Tablespace, Free Space, Used Space and the vital, Date of Sample.
You’ll get the information from just three views of the Oracle Data Dictionary views: DBA_DATA_FILES, DBA_FREE_SPACE, V$PARAMETER. This is a sample of the query used.
SELECT p.value, to_char(sysdate,'DD-MM-YYYY'), d.tablespace_name, NVL (a.BYTES / 1024 / 1024, 0), NVL (a.BYTES - NVL (f.BYTES, 0), 0) / 1024 / 1024)FROM SYS.dba_tablespaces d, (SELECT tablespace_name, SUM (BYTES) BYTES FROM dba_data_files GROUP BY tablespace_name) a, (SELECT tablespace_name, SUM (BYTES) BYTES FROM dba_free_space GROUP BY tablespace_name) f, v$parameter pWHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+) AND NOT (d.extent_management LIKE 'LOCAL' AND d.CONTENTS LIKE 'TEMPORARY') AND p.name like '%instance%name%'
To be Continued… (growth patterns)
Please, before you go, don’t forget to vote the poll regarding the content of this blog, thank you!
Compression … expensive or cheap?
We may take the point of view of information explotion, then we think it’s a never ending story…at least that’s the looouuuud complain the business and companies we work for, make every given years that they need to double or triplicate our SAN (read: any-storage-device-you own), expend some million bucks… and save for next loop. But it’s a fact to be faced: information is being generated almost compulsively, even by devices a couple years ago where merely information ‘mute’.
The scenario seems to get more complicated for years to come…
What if we look the recent direction microprocessor development has taken: multicore processors, devices with 2 or 4 or n independent processing units on one package. Visionary projects like Intel Terascale or IBM-Sony-Toshiba Cell will provide tremendous processing power.
And this huge leap forward takes processing growth rate much ahead of storage growth rate. Then, such powerhouses may help mitigate the information avalanche we live on… what do you think?
Before 11g
Yes, we may talk about compression before 11g, of course there isn’t much noise about it because it’s an incomplete feature on 10g, with restrictions that make it almost useless for regular OLTP applications: only works when data is inserted direct-path mode, that is bulk insert and Import Datapump (sorry, regular import doesn’t have it).
But not everything is lost, there are some scenarios where it still can be usefull, very I must say.
1) Cut significantly storage for Historic/Archive and Testing/Development environments
2) Reduce IO (and increase performance) on Datawarehousing/BI applications
I’ve done comparative tests, showing that 10g compression gives a very good rate, reducing storage usage by 45% – 60%. I’m saying you may double your SAN “space-life” or slice the storage invoice, specially on scenario (1) when you fight fierce battles for budget that won’t support direct business’ operations.
With 11g
Oracle 11g offers data compression, but what are the benefits? what do we have to pay?
Please, before you go, don’t forget to vote the poll regarding the content of this blog, thank you!
