Ad Nauseum, an interesting term. Usually used to indicate that a subject has continued beyond its useful lifetime. Several experts seem to want to continue on such subjects as index rebuilding, clustering factor discussions and updating data dictionary tables ad nauseum. I for one find it odd they have so much free time. Perhaps I should be complemented they feel this drive to snap at my heals so much.
Note to Oracle: Perhaps you should find more for your experts to do, they seem to be caught in a rut.
I have stated my opinions on the subjects of indexes, clustering factors and data dictionary tables. I see no need to reiterate them. I have recanted incorrect advice I have given in the past. It is time to move on. Aren't there more interesting topics? Or perhaps they find, rather like Pro Wrestling draws a number of viewers, a good bash fest draws in more readers. I guess that is what happens when there is no technical content they can present as their own.
Learning is an iterative process, and during that time mistakes can and will be made. However if every time someone makes a misstatement or an error we bash them about the head and shoulders and then remind them of their past mistakes at every opportunity, they will soon cease learning altogether. Makes me wonder how these other experts treat their co-workers and clients, if they berate them at every opportunity it is no wonder they have so much free time.
As for me, I have too much to do to worry overmuch about what tripe they are currently dishing up, in fact, I plan not to respond to them any longer as I am reminded of an old country saying:
"It does no good to get down in the mud and wrestle with pigs, you can't win and the pigs enjoy it."
So I shall spend my time working for my clients, researching and documenting Oracle behaviors, tips and techniques and acquiring new skills. Perhaps if these other experts would spend as much energy on putting out new material as they do circling the same issues over and over we would all benefit.
Tuesday, April 26, 2005
Saturday, April 16, 2005
Standing By
In several posts at various Oracle related forums I have been taken to task for standing by Don Burleson. In the past I was also taken to task for standing by others such as Rich Niemiec. I have been repeatedly asked why I don't attack, belittle or otherwise "take on" many other experts.
Well, first, I believe people are entitled to their opinions.
Second, both of the above I consider to be friends. Where I come from you stand by your friends in public. Now in private I may tell them they are incorrect and suggest they alter their viewpoints, postings or papers, but not in a public forum where it could humiliate or embarrass them.
Others seem to enjoy laying about with wild abandon when someone is mistaken, falling all over each other like the spider creatures eating their wounded in the remake of "Lost In Space". They seem to enjoy laying scorn and abuse on others. This behavior is counter productive and leads to outright fear on the part of many neophytes about writing papers, posting answers or helping anyone anywhere online.
Of course the very folks that attack with guns blazing seem most upset when you fight back, rather like a school yard bully. They expect you to roll over and show your soft spots like a cur giving into a stronger dog. Sorry, can't do that, never did it, won't do it.
I will admit mistakes, and correct them when possible. I have done this in the past and will do it in the future. However I am a strong believer in positive feedback being more beneficial than negative feedback. I rarely listen to feedback that begins something like "You worthless git, your book/paper/presentation/tip is all bloody trash". However, I always open to "Mike, the tip is interesting, but here is a problem with what you have said", I may argue a bit, but I will listen and try to improve my knowledge and abilities. Be that as it may, you attack me in a public forum, I have no compunction about taking you to task over it, also in a public forum.
Anyway, enough rant.
Well, first, I believe people are entitled to their opinions.
Second, both of the above I consider to be friends. Where I come from you stand by your friends in public. Now in private I may tell them they are incorrect and suggest they alter their viewpoints, postings or papers, but not in a public forum where it could humiliate or embarrass them.
Others seem to enjoy laying about with wild abandon when someone is mistaken, falling all over each other like the spider creatures eating their wounded in the remake of "Lost In Space". They seem to enjoy laying scorn and abuse on others. This behavior is counter productive and leads to outright fear on the part of many neophytes about writing papers, posting answers or helping anyone anywhere online.
Of course the very folks that attack with guns blazing seem most upset when you fight back, rather like a school yard bully. They expect you to roll over and show your soft spots like a cur giving into a stronger dog. Sorry, can't do that, never did it, won't do it.
I will admit mistakes, and correct them when possible. I have done this in the past and will do it in the future. However I am a strong believer in positive feedback being more beneficial than negative feedback. I rarely listen to feedback that begins something like "You worthless git, your book/paper/presentation/tip is all bloody trash". However, I always open to "Mike, the tip is interesting, but here is a problem with what you have said", I may argue a bit, but I will listen and try to improve my knowledge and abilities. Be that as it may, you attack me in a public forum, I have no compunction about taking you to task over it, also in a public forum.
Anyway, enough rant.
Wednesday, April 13, 2005
Going Solid
(Note: This is a blog on a specific technical topic, solid state disk drives, any responses not germane to this topic will be deleted.)
Back in my days as a Nuclear Machinest Mate/ELT on board submarines in the USN, there was a condition known as "going solid" which referred to a controlled process where by the bubble of steam in the reactor coolant loop pressurizer was slowly compressed to force it back into water thus making the entire reactor loop solid with water. Under controlled conditions this was done for various reasons, if it happened by accident it was not good as you would have lost pressure control for the reactor cooling loop. So going solid in those days was both good (if done as a controlled exercise) and possibly very bad (if allowed to happen accidentally.) But that is not what I am referring to in this blog as going solid.
What I am referring to is the new trend (well, actually it has been around since the 90's) to move databases to solid state drives. In almost all cases this form of going solid leads to measurable performance improvements by elimination of the various latencies involved with the standard computer disk drive assemblies. Of course the removal of disk rotational and arm latencies is just one of the things that solid state drives bring to the table, the other is access to your data at near-memory speeds.
What solid state drives mean to an application is that if your application is currently suffering from IO problems some if not all of them are relieved. However, the benefits are a bit lop sided depending on the predominant type of IO wait your system is seeing. If your IO waits are due to contention during the retrieval of information (SELECT statements) then you can expect a dramatic increase in performance. In tests against standard disk arrays using the TPC-H benchmark I was able to achieve a 176 times performance increase for primarily retrieval based transactions. For what I refer to as IUD transactions (INSERT, UPDATE and DELETE) only a 30-60% performance improvement was shown.
Remember that retrieval requires no additional processing once the data location is returned from the search process, while IUD involves data verification via indexes, constraints and other internal processes that tend to slow down the process thus reducing the performance gains. Does solid state disk (SSD) technology eliminate waits? Of course not, what it does is reduce their duration. For example, looking at load times:
Load Graph Using SSD
You can from the graph that load times for standard disks was on the average about 30% slower than the load times for an equivalent SSD drive array.
However looking at query response time, we see an entirely different picture:
SSD Queries
When we compare the SSD times with the same queries, same OS settings and same layout on standard drives, we see a dramatic difference (notice the scale on this next graph is logarithmic, not linear):
ATA Queries
The second graph really drives home the point, I had to make it logarithmic because of the great differences in time duration for the various queries when going to disks. What required a couple of hours (running the 20+ base queries) on SSD required 3 days on the average for the ATA drives.
Of course we don't remove the IO waits by using SSD, their duration is simply reduced to the point they are not a big factor anymore. Of course, for scalability and such you still will need to tune SQL.
Some how, I see going solid in our future.
For a complete copy of the testing look at:
http://www.rampant-books.com/book_2005_1_ssd.htm
For the latest in Solid State Drives look at:
http://www.texmemsys.com/
Back in my days as a Nuclear Machinest Mate/ELT on board submarines in the USN, there was a condition known as "going solid" which referred to a controlled process where by the bubble of steam in the reactor coolant loop pressurizer was slowly compressed to force it back into water thus making the entire reactor loop solid with water. Under controlled conditions this was done for various reasons, if it happened by accident it was not good as you would have lost pressure control for the reactor cooling loop. So going solid in those days was both good (if done as a controlled exercise) and possibly very bad (if allowed to happen accidentally.) But that is not what I am referring to in this blog as going solid.
What I am referring to is the new trend (well, actually it has been around since the 90's) to move databases to solid state drives. In almost all cases this form of going solid leads to measurable performance improvements by elimination of the various latencies involved with the standard computer disk drive assemblies. Of course the removal of disk rotational and arm latencies is just one of the things that solid state drives bring to the table, the other is access to your data at near-memory speeds.
What solid state drives mean to an application is that if your application is currently suffering from IO problems some if not all of them are relieved. However, the benefits are a bit lop sided depending on the predominant type of IO wait your system is seeing. If your IO waits are due to contention during the retrieval of information (SELECT statements) then you can expect a dramatic increase in performance. In tests against standard disk arrays using the TPC-H benchmark I was able to achieve a 176 times performance increase for primarily retrieval based transactions. For what I refer to as IUD transactions (INSERT, UPDATE and DELETE) only a 30-60% performance improvement was shown.
Remember that retrieval requires no additional processing once the data location is returned from the search process, while IUD involves data verification via indexes, constraints and other internal processes that tend to slow down the process thus reducing the performance gains. Does solid state disk (SSD) technology eliminate waits? Of course not, what it does is reduce their duration. For example, looking at load times:
Load Graph Using SSD
You can from the graph that load times for standard disks was on the average about 30% slower than the load times for an equivalent SSD drive array.
However looking at query response time, we see an entirely different picture:
SSD Queries
When we compare the SSD times with the same queries, same OS settings and same layout on standard drives, we see a dramatic difference (notice the scale on this next graph is logarithmic, not linear):
ATA Queries
The second graph really drives home the point, I had to make it logarithmic because of the great differences in time duration for the various queries when going to disks. What required a couple of hours (running the 20+ base queries) on SSD required 3 days on the average for the ATA drives.
Of course we don't remove the IO waits by using SSD, their duration is simply reduced to the point they are not a big factor anymore. Of course, for scalability and such you still will need to tune SQL.
Some how, I see going solid in our future.
For a complete copy of the testing look at:
http://www.rampant-books.com/book_2005_1_ssd.htm
For the latest in Solid State Drives look at:
http://www.texmemsys.com/
Monday, April 11, 2005
Why No Comments
(Note: I have modified this blog, I stated in the first verison that the SQL execution plans didn't change, when actually we can't be sure, but from the bug reports and other statistics we gathered I had inferred this, sorry if I misled anyone.)
I have received a couple of rejoiners about not allowing comments on my last blog. I did this because I found that the people who were responding to other posts spent more time being negative than positive, more time tearing down then building up and more time to offer vindictive rather than constructive comments.
This entry, as the last, will not be allowing comments because I want it to stand by itself. When I make the next blog after this one, I will open it back up for comments. I indulged a bit of vindictive myself with my last blog, maybe it was justfied, maybe not. I just get tired of the self righteous experts out there that believe their way is the only way. I try to embrace whatever technologies will help my clients.
Let me explain how a typical client visit goes:
1. We get the call and issue a contract for the visit, let's say for a Database Healthcheck
2. The contract is assigned to a Senior DBA and it is determined to be either an onsite or remote job.
3. If onsite we go to the client and first review what problems they perceive they are having. This helps establish the parameters of the initial monitoring.
4. We then establish connectivity to the instance(s) to be monitored.
5. Using Oracle provided and self generated monitoring scripts the database is analyzed, usually for (not a complete list):
A. Wait events
B. IO spread and timing
C. Log events
D. Memory statistics and parameters
E. SQL usage
F. SQL statements which require too many resources
G. Access statistics if in 9i and 10g, otherwise major problem SQL is analyzed.
H. Parameter settings
6. The server is monitored for:
A. Disk IO
B. CPU usage statistics
C. Memory usage statistics
7. The system is reviewed for security and backup and recovery processes.
Usually one or more of the above causes the need for additional monitoring or analysis in a specific area, as time allows, this is done.
Using all of the above data, a detailed list of recommendations is prepared with actionable statements giving specific fixes and time estimates for the fixes. The "low hanging fruit" such as improvements to settings, server settings, addition of needed indexes, etc, are done, in a test environment if possible and the results analyzed (again if time and site procedures allow). The results of the analysis of the changes and the original data is used to prepare a final report with the actions suggested, actions taken, the results of the actions and the list of recommendations that still need to be implemented. Usually we include a whitepaper or two about the various techniques we may recommend.
We never go onsite and start issuing recommendations without analysis. The last time I saw this technique used was from Oracle support three days ago. Without looking at detailed statistics or analysis they suggested increasing the shared pool (even though all of it wasn't being used), increasing the database cache size (even though 30% of the buffers were free in V$BH), turn off MTS (we had already tried this and it made no difference) and several other Oracle "Silver Bullets", none of which made the slightest difference in the problem. It turned out the problem was that 10g has a default value of TRUE for the parameter _B_TREE_BITMAP_PLANS which, even though the application had been running for months, suddenly started making a difference. Note there were no bitmaps in the database other than those that Oracle had in their schemas. They offered no proofs, no explanations, just a sigh of relief that this Oracle Silver Bullet fixed the problem.
This is a classic example of why "simple", "repeatable" proofs can be hazardous. By all of the indications there was nothing wrong at the database level. No waits or events showed the problem, even plans for the SQL appaerently didn't change, since it was a systemic problem (any SQL causes the issue not just specific SQL) we didn't check plans before the fix was provided by Oracle support. Any SQL activity resulted in CPU spiking of up to 70-80%. However, the setting of this undocumented parameter had a profound effect on the optimizer and overall database performance. If an Oracle analyst hadn't "seen this before" and remembered this "Silver Bullet" the client would still be having problems. The troubled queries dropped form taking several minutes to 6 seconds.
When going from 7 to 8 to 8i to 9i to 10g Oracle has been notorious for resetting their undocumented parameters from true to false, false to true, adding new undocumented and documented parameters and of course varying the various number based parameters to get the right "mix". You have to understand this in order to trouble shoot Oracle performance problems. Even within the same release some of these change based on platform.
This is the point I am trying to make about single user, small database proofs, they are great for documenting Oracle behavior on single user, small databases. They would have been completely useless in this case.
Unless the "test" environment reached whatever trigger size caused the parameter to take precedence you could type in various proofs until your fingers were bloody and they would not have helped one iota.
In order to fully perceive a problem you have to look at it carefully, from both an atomic level and a holistic level or you will miss the tru solution in many cases. In others, you may know the solution (the application needs to be re-written) but it may be impossible to implement, either because of time or resource limits or because of support limits from vendors. In this case you must be prepared to treat symptoms to allow the database to function at an acceptable level.
That is the long and short of it.
I have received a couple of rejoiners about not allowing comments on my last blog. I did this because I found that the people who were responding to other posts spent more time being negative than positive, more time tearing down then building up and more time to offer vindictive rather than constructive comments.
This entry, as the last, will not be allowing comments because I want it to stand by itself. When I make the next blog after this one, I will open it back up for comments. I indulged a bit of vindictive myself with my last blog, maybe it was justfied, maybe not. I just get tired of the self righteous experts out there that believe their way is the only way. I try to embrace whatever technologies will help my clients.
Let me explain how a typical client visit goes:
1. We get the call and issue a contract for the visit, let's say for a Database Healthcheck
2. The contract is assigned to a Senior DBA and it is determined to be either an onsite or remote job.
3. If onsite we go to the client and first review what problems they perceive they are having. This helps establish the parameters of the initial monitoring.
4. We then establish connectivity to the instance(s) to be monitored.
5. Using Oracle provided and self generated monitoring scripts the database is analyzed, usually for (not a complete list):
A. Wait events
B. IO spread and timing
C. Log events
D. Memory statistics and parameters
E. SQL usage
F. SQL statements which require too many resources
G. Access statistics if in 9i and 10g, otherwise major problem SQL is analyzed.
H. Parameter settings
6. The server is monitored for:
A. Disk IO
B. CPU usage statistics
C. Memory usage statistics
7. The system is reviewed for security and backup and recovery processes.
Usually one or more of the above causes the need for additional monitoring or analysis in a specific area, as time allows, this is done.
Using all of the above data, a detailed list of recommendations is prepared with actionable statements giving specific fixes and time estimates for the fixes. The "low hanging fruit" such as improvements to settings, server settings, addition of needed indexes, etc, are done, in a test environment if possible and the results analyzed (again if time and site procedures allow). The results of the analysis of the changes and the original data is used to prepare a final report with the actions suggested, actions taken, the results of the actions and the list of recommendations that still need to be implemented. Usually we include a whitepaper or two about the various techniques we may recommend.
We never go onsite and start issuing recommendations without analysis. The last time I saw this technique used was from Oracle support three days ago. Without looking at detailed statistics or analysis they suggested increasing the shared pool (even though all of it wasn't being used), increasing the database cache size (even though 30% of the buffers were free in V$BH), turn off MTS (we had already tried this and it made no difference) and several other Oracle "Silver Bullets", none of which made the slightest difference in the problem. It turned out the problem was that 10g has a default value of TRUE for the parameter _B_TREE_BITMAP_PLANS which, even though the application had been running for months, suddenly started making a difference. Note there were no bitmaps in the database other than those that Oracle had in their schemas. They offered no proofs, no explanations, just a sigh of relief that this Oracle Silver Bullet fixed the problem.
This is a classic example of why "simple", "repeatable" proofs can be hazardous. By all of the indications there was nothing wrong at the database level. No waits or events showed the problem, even plans for the SQL appaerently didn't change, since it was a systemic problem (any SQL causes the issue not just specific SQL) we didn't check plans before the fix was provided by Oracle support. Any SQL activity resulted in CPU spiking of up to 70-80%. However, the setting of this undocumented parameter had a profound effect on the optimizer and overall database performance. If an Oracle analyst hadn't "seen this before" and remembered this "Silver Bullet" the client would still be having problems. The troubled queries dropped form taking several minutes to 6 seconds.
When going from 7 to 8 to 8i to 9i to 10g Oracle has been notorious for resetting their undocumented parameters from true to false, false to true, adding new undocumented and documented parameters and of course varying the various number based parameters to get the right "mix". You have to understand this in order to trouble shoot Oracle performance problems. Even within the same release some of these change based on platform.
This is the point I am trying to make about single user, small database proofs, they are great for documenting Oracle behavior on single user, small databases. They would have been completely useless in this case.
Unless the "test" environment reached whatever trigger size caused the parameter to take precedence you could type in various proofs until your fingers were bloody and they would not have helped one iota.
In order to fully perceive a problem you have to look at it carefully, from both an atomic level and a holistic level or you will miss the tru solution in many cases. In others, you may know the solution (the application needs to be re-written) but it may be impossible to implement, either because of time or resource limits or because of support limits from vendors. In this case you must be prepared to treat symptoms to allow the database to function at an acceptable level.
That is the long and short of it.
In a Galaxy Far, Far Away...
I read with amusement many of the “experts” posts, both as comments here and at many other websites. In my mind I imagine a conversation between these experts and my typical client (note, SATIRE SWITCH ON (I have never been present at a conversation between these experts and a client))
Client: Welcome to Acme! We have been looking forward to your visit! We really have some problems we want help with!
Expert: Good, as you know I am an expert and am here to help.
Client: Ok, where do you want to setup? Do you need connection to the database?
Expert: The CIO office would be nice.
Client: Well, errr, we have this cubical we set up for you.
(Looking down their nose) Expert: If I must.
(Looking relieved) Client: Great, it is right over here.
Client: How do you want to start?
Expert: I will have to look at all you data, its relationships to each other and how you use it.
(Looking concerned)Client: I’ll have to get that approved. How long do you think it will take?
Expert: Not longer than 2-3 weeks tops.
Client: 2-3 Weeks! At your rate that’s (getting out calculator) $54,000.00!
Expert: I am an expert and work directly for XXX. Is there a problem? (looking intimidating)
Client: Well, we had hoped to get it sooner, I will see about getting approval.
Expert: After that I will need to study the physical relationships of your entire database, how all the indexes are built, how all the tables are configured, and do root cause analysis of all waits and events.
(Looking impressed) Client: Wow! How long will that take?
Expert: Oh, not long, maybe another 3 weeks if I work overtime.
(Looking really concerned now)Client: That would mean more than $108,000.00…
Expert: Do you want this database to perform or not?
Client: Of course we want it to perform, that is why we brought you in. There may be some issues though…
Expert: How so?
Client: According to HIPPA and SOX, we can’t grant you access to our data and we are running a third-part application and can’t touch the code.
(Picking up laptop case) Expert: Sorry, I can’t help you, what do you think I am? Burleson Consulting? I can’t be expected to tune without changing the code, I don’t believe in silver-bullets that can be applied globally and if I don’t completely understand your data, structures, indexes and tables I simply can’t make any recommendations. You’ll get my bill.
Client: What was that name you mentioned?
(SATIRE SWITCH OFF)
Client: Welcome to Acme! We have been looking forward to your visit! We really have some problems we want help with!
Expert: Good, as you know I am an expert and am here to help.
Client: Ok, where do you want to setup? Do you need connection to the database?
Expert: The CIO office would be nice.
Client: Well, errr, we have this cubical we set up for you.
(Looking down their nose) Expert: If I must.
(Looking relieved) Client: Great, it is right over here.
Client: How do you want to start?
Expert: I will have to look at all you data, its relationships to each other and how you use it.
(Looking concerned)Client: I’ll have to get that approved. How long do you think it will take?
Expert: Not longer than 2-3 weeks tops.
Client: 2-3 Weeks! At your rate that’s (getting out calculator) $54,000.00!
Expert: I am an expert and work directly for XXX. Is there a problem? (looking intimidating)
Client: Well, we had hoped to get it sooner, I will see about getting approval.
Expert: After that I will need to study the physical relationships of your entire database, how all the indexes are built, how all the tables are configured, and do root cause analysis of all waits and events.
(Looking impressed) Client: Wow! How long will that take?
Expert: Oh, not long, maybe another 3 weeks if I work overtime.
(Looking really concerned now)Client: That would mean more than $108,000.00…
Expert: Do you want this database to perform or not?
Client: Of course we want it to perform, that is why we brought you in. There may be some issues though…
Expert: How so?
Client: According to HIPPA and SOX, we can’t grant you access to our data and we are running a third-part application and can’t touch the code.
(Picking up laptop case) Expert: Sorry, I can’t help you, what do you think I am? Burleson Consulting? I can’t be expected to tune without changing the code, I don’t believe in silver-bullets that can be applied globally and if I don’t completely understand your data, structures, indexes and tables I simply can’t make any recommendations. You’ll get my bill.
Client: What was that name you mentioned?
(SATIRE SWITCH OFF)
Saturday, April 09, 2005
Rumor Control
It seems numerous rumors and comments are being posted in the comments sections about things I may have once said, but upon research found were incorrect and retracted. Let me reiterate:
1. I have not found a case were an index rebuild, without re-arrangement of columns or change to the index structure, changes the clustering factor. Any prior advice I gave (nearly 2 years ago or so) to the contrary is incorrect.
2. I completely understand that the multiple block size feature in Oracle has limitations. I recommend them where the limitations are not a factor. That I haven't written a multi-page report on this fact with several more pages of complex proof, simply to prove what others have already done and is well documented in Oracle documentation I apologize for, I simply don't have the time to waste reinventing wheels.
3. The simple rules I mentioned in previous posts referred to the rules for database physical, PL/SQL and SQL design that are put forth in many of the Oak Table books, Oracle Press books and Rampant Books. Unfortunately, people don't follow these rules, the rules were made after the applications were designed, the people bought third party solutions that never follow any rules (good or bad), the people can't/won't change the code or a myriad set of other reasons that the good practices are not put in place. This is the real-world I dwell in and have to deal with.
4. I have never claimed that my advice on rebuilding indexes only applied to bitmaps, never have, never will. There are several situations where rebuilding or coalescing of indexes is beneficial and when I see a need for it, I will recommend it.
5. Why have I not attacked Don Burleson. Well, why have Howard and Tom never attacked Oracle for the many stupid things Oracle has done in the design and implementation of the Oracle product? For Oracle’s handling of support issues? For Oracle supports use of their own set of silver bullets? Also, Don has not attacked me. I am not confrontational by nature, I tend to let others have their opinions. When I can, I take Don to task in private for things which may be inaccurate, it is up to Don to change if he agrees with me. If I don't agree with everything Don advises, well, that is my opinion. It is rather like the TV, if you don't like what is being said, switch to another channel.
6. As to my opinions about asktom, yes, there are many good things there, there are also bad things as with any public forum. My major problem is that while it is supported by Oracle Corp. and supposedly moderated, I see things there that violate Oracles rules of conduct and should not be allowed on a moderated site. The examples are in the article, you can go to those links and see for yourself. Tom is excellent at providing proofs for his environment. But he rarely states "This proof should only be taken for proof in a similar environment to mine, your mileage may differ" and the very neofites you fear Don's and my advice will mislead, will be just as easily misled by correct proofs for an improper environment.
I attempt to avoid name-calling, bashing of others, and in general clouding issues with emotion charged clap-trap. In specific cases I have fought back when attacked by others and will continue to do so.
Oracle users tend to be a vocal lot. If advice causes problems it is generally well shouted from the roof tops. I task you Howard in presenting these shouts, if you cannot then you are but another chicken little proclaiming the sky is falling.
Any advice, when used incorrectly or without consideration is bad advice. Anyone who blindly follows suggestions, no matter what the source, without testing it in a test environment, deserves what they get.
If an automotive expert suggested I put water in my gas tank, I would question that advice, not blindly follow it. Compared to virtually all auto experts I am a neophyte in that area but I know not to blindly follow advice. When I go to a Doctor, an area I am definitely not trained in, if the advice sounds absurd I go to a second Doctor for their advice. There is no shortage of advice on Oracle, a quick check of Metalink, OTN and Google will find a plethora of opinions, demos, and advice on virtually any facet of Oracle administration you can imagine.
As I have said before, I have real work to do, I need to consolidate a list of 32 findings into something that can be accomplished with maximum return in 5 days. Not 2 weeks, not a month of study and testing, 5 days. Again, this is the real world.
1. I have not found a case were an index rebuild, without re-arrangement of columns or change to the index structure, changes the clustering factor. Any prior advice I gave (nearly 2 years ago or so) to the contrary is incorrect.
2. I completely understand that the multiple block size feature in Oracle has limitations. I recommend them where the limitations are not a factor. That I haven't written a multi-page report on this fact with several more pages of complex proof, simply to prove what others have already done and is well documented in Oracle documentation I apologize for, I simply don't have the time to waste reinventing wheels.
3. The simple rules I mentioned in previous posts referred to the rules for database physical, PL/SQL and SQL design that are put forth in many of the Oak Table books, Oracle Press books and Rampant Books. Unfortunately, people don't follow these rules, the rules were made after the applications were designed, the people bought third party solutions that never follow any rules (good or bad), the people can't/won't change the code or a myriad set of other reasons that the good practices are not put in place. This is the real-world I dwell in and have to deal with.
4. I have never claimed that my advice on rebuilding indexes only applied to bitmaps, never have, never will. There are several situations where rebuilding or coalescing of indexes is beneficial and when I see a need for it, I will recommend it.
5. Why have I not attacked Don Burleson. Well, why have Howard and Tom never attacked Oracle for the many stupid things Oracle has done in the design and implementation of the Oracle product? For Oracle’s handling of support issues? For Oracle supports use of their own set of silver bullets? Also, Don has not attacked me. I am not confrontational by nature, I tend to let others have their opinions. When I can, I take Don to task in private for things which may be inaccurate, it is up to Don to change if he agrees with me. If I don't agree with everything Don advises, well, that is my opinion. It is rather like the TV, if you don't like what is being said, switch to another channel.
6. As to my opinions about asktom, yes, there are many good things there, there are also bad things as with any public forum. My major problem is that while it is supported by Oracle Corp. and supposedly moderated, I see things there that violate Oracles rules of conduct and should not be allowed on a moderated site. The examples are in the article, you can go to those links and see for yourself. Tom is excellent at providing proofs for his environment. But he rarely states "This proof should only be taken for proof in a similar environment to mine, your mileage may differ" and the very neofites you fear Don's and my advice will mislead, will be just as easily misled by correct proofs for an improper environment.
I attempt to avoid name-calling, bashing of others, and in general clouding issues with emotion charged clap-trap. In specific cases I have fought back when attacked by others and will continue to do so.
Oracle users tend to be a vocal lot. If advice causes problems it is generally well shouted from the roof tops. I task you Howard in presenting these shouts, if you cannot then you are but another chicken little proclaiming the sky is falling.
Any advice, when used incorrectly or without consideration is bad advice. Anyone who blindly follows suggestions, no matter what the source, without testing it in a test environment, deserves what they get.
If an automotive expert suggested I put water in my gas tank, I would question that advice, not blindly follow it. Compared to virtually all auto experts I am a neophyte in that area but I know not to blindly follow advice. When I go to a Doctor, an area I am definitely not trained in, if the advice sounds absurd I go to a second Doctor for their advice. There is no shortage of advice on Oracle, a quick check of Metalink, OTN and Google will find a plethora of opinions, demos, and advice on virtually any facet of Oracle administration you can imagine.
As I have said before, I have real work to do, I need to consolidate a list of 32 findings into something that can be accomplished with maximum return in 5 days. Not 2 weeks, not a month of study and testing, 5 days. Again, this is the real world.
Saturday, March 26, 2005
Lack of Compassion?
I recently read an article in Utne magazine (online at http://www.utne.com/) entitles "Dying for Lobster" that, as a diver left me horrified. For those of you who aren't divers, when you dive and breath air under pressure, more than normal amounts of nitrogen are forced into your blood, as long as you dive within proper limits and follow proper safety, this nitrogen comes back out without causing problems. However, if you push the limits, don't follow safety rules (for example, staying down to long and ascending to fast) then the nitrogen comes out too fast, like bubbles of gas in a soda can. The gas is likely to come out at joints and as a rash at the surface of the skin. Oh, it also comes out in the brain and spinal cord, causing stroke like symptoms and paralysis. This is called decompression illness, you may have heard it called "the bends." If you are rushed to a decompression chamber the symptoms in many cases can be reversed, although there can be residual side effects.
Anyway, the article talked about Nicaraguan divers who dive for lobster from lobster company boats. These divers dive with poor equipment, no depth or pressure gage, no dive computers. They may dive 15 or more times a day to depths of 120 feet or more. I am sure they are encourged to bring up as many lobsters as they can each day. This means they ignore bottom time limits (if they are even taught them) and ignore safe ascent rates (again if they are even taght them.) As a result many of them "get bent" and unfortunately, since these boats are out for 2-3 weeks, don't get the benefit of getting taken to a deco chamber until it is too late. This results in many being crippled for life and many die.
On a Scuba board I suggested setting up a donation center for used dive equipment that is still servicable. Most of this equipment moulders away in closets, or is sold on ebay for a fraction of its worth. Since there is already a tax-exempt group set up to provide deco chambers for the divers I thought we could probably set up with them to provide tax receipts (at least to USA divers) for donated equipment that they could then use for reducing their taxes. The Nicaraguan divers win, we win. We would also provide training manuals and training to help these divers understand how to avoid the injuries from bends and how to use the more complex dive computers.
I understand that this is not correcting the problem, the exploitation of the workers and a government that doesn't care, but we really can't do much about that. We can make these divers safe divers and ease or prevent their suffering. To a response, all responses on the Scuba board were negative. No one saw the benefit of helping the divers, no one offered spare equipment.
Several of the more vocal respondents were from Canada, and I thought Canadians were a warm, friendly people who wanted to help others. Most were from the USA. I thought there would be more compassion for the plight of these divers, I thought there would be more generosity. I was wrong.
One diver said Red Lobster was the number one purchaser of the lobsters, I haven't confirmed that, nor do I know how to confirm it, if someone could I would appreciate it. Anyway, would a boycott help? The main reason the divers there dive is for the money. For 2-3 weeks of 15 dives a day and risking their health and lives they make $300.00 and room an board. Now for their economy this is good money, right up to the point where it kills them. In a boycott, if it was 100% successful, would it help these divers? It might eliminate their livelihood and throw them back into abject poverty, I am sure they would thank us. Through education and the provision of better equipment we would improve the quality of their lives, and as a side effect, reduce the pressure on the lobster population as limiting bottom time would reduce the number taken.
I hate to think the divers may have been motivated by the thought that they could get more money for the used equipment by selling it rather than donating it. I also hate to think they are so naive as to think we could change the government there and make it more compassionate (haven't we spent billions to do that with no visible affect?.) I also hate to think they care more about lobsters than they do men.
Anyway, the article talked about Nicaraguan divers who dive for lobster from lobster company boats. These divers dive with poor equipment, no depth or pressure gage, no dive computers. They may dive 15 or more times a day to depths of 120 feet or more. I am sure they are encourged to bring up as many lobsters as they can each day. This means they ignore bottom time limits (if they are even taught them) and ignore safe ascent rates (again if they are even taght them.) As a result many of them "get bent" and unfortunately, since these boats are out for 2-3 weeks, don't get the benefit of getting taken to a deco chamber until it is too late. This results in many being crippled for life and many die.
On a Scuba board I suggested setting up a donation center for used dive equipment that is still servicable. Most of this equipment moulders away in closets, or is sold on ebay for a fraction of its worth. Since there is already a tax-exempt group set up to provide deco chambers for the divers I thought we could probably set up with them to provide tax receipts (at least to USA divers) for donated equipment that they could then use for reducing their taxes. The Nicaraguan divers win, we win. We would also provide training manuals and training to help these divers understand how to avoid the injuries from bends and how to use the more complex dive computers.
I understand that this is not correcting the problem, the exploitation of the workers and a government that doesn't care, but we really can't do much about that. We can make these divers safe divers and ease or prevent their suffering. To a response, all responses on the Scuba board were negative. No one saw the benefit of helping the divers, no one offered spare equipment.
Several of the more vocal respondents were from Canada, and I thought Canadians were a warm, friendly people who wanted to help others. Most were from the USA. I thought there would be more compassion for the plight of these divers, I thought there would be more generosity. I was wrong.
One diver said Red Lobster was the number one purchaser of the lobsters, I haven't confirmed that, nor do I know how to confirm it, if someone could I would appreciate it. Anyway, would a boycott help? The main reason the divers there dive is for the money. For 2-3 weeks of 15 dives a day and risking their health and lives they make $300.00 and room an board. Now for their economy this is good money, right up to the point where it kills them. In a boycott, if it was 100% successful, would it help these divers? It might eliminate their livelihood and throw them back into abject poverty, I am sure they would thank us. Through education and the provision of better equipment we would improve the quality of their lives, and as a side effect, reduce the pressure on the lobster population as limiting bottom time would reduce the number taken.
I hate to think the divers may have been motivated by the thought that they could get more money for the used equipment by selling it rather than donating it. I also hate to think they are so naive as to think we could change the government there and make it more compassionate (haven't we spent billions to do that with no visible affect?.) I also hate to think they care more about lobsters than they do men.
Tuesday, March 22, 2005
Stray Thoughts
It is amazing the things that come to mind just as you are drifting off to sleep. Old memories, new thoughts, the answer to that annoying question. I guess it shows that the mind is continuously at work processing things that we see and hear, sometimes long after we have stopped thinking about them on the surface.
Last night for example religion for some reason was paramount in my mind as I started to drift off. I remembered such adages as "God helps them that help themselves", and the parable of the servants and the money which goes something like "A master gave three servants each some money and instructed them to take care of it while he was gone. One went out and invested it, another used it to buy grain and plant it, while the third buried it. Upon the masters return each was called into accounting for the money they had been given, the first gave back two fold, the second was unable to give back crops because of a blight, the third gave back exactly what he was given. The master praised the two who had invested and put the money to work and rewarded them, even though the second had lost the money, the third, who only hid the money to return the exact amount, was punished." forgive any paraphrasing...
It seems to me that many of the fundamentalist beliefs are rather like the third servant. They take the coin of heaven and attempt to return it without changing it, improvement or loss. They feel that to question, challenge or add to the amount given (I am not talking about how many you add to the numbers of the church, I am talking about knowledge) is in some way forbidden, as if the holy book sprung, not from the labor of hundreds of people over thousands of years, but whole and perfect from the hand of God. When there are errors in translation, errors in usage, errors in understanding, they accept this all as whole cloth, not weaving more, not patching the holes, and not washing the stains away.
This happens of course not only in religion, but in life as well. In technical areas we have our own version of the GI-GO syndrome (garbage in - garbage out) known as garbage-in-gospel-out (I talked about this in an article back in the late 80's), that portends if it issues from a computer it must be gospel. In law we base everything on precedents, as if those in the past were smarter, more enlightened and knew more about the current situation than we do.
I believe that each person has the responsibility to learn as much as they can. We are all our own product. Many times people have accused me of being, shall I say eclectic? To which a say thanks. Having read at last estimate over 3000 or so books in my lifetime (give or take 100 or so) and hoping to read at least another 3000 before I pass into my reward, I find it gives me quite a platform on which to stand while I reach for more. Reach for more understanding. more knowledge and more insight that is. My reading reaches from technical and religious books to science fiction, historical fiction and the occasional horror or action adventure. Each book has something to teach, if you limit your reading on any topic to just one author, your horizon will be limited.
In a recent conversation someone dear to me expressed horror that I would read certain books by authors who disagreed with that persons basic belief structure. Words are only given power by the reader. I read what gives me more understanding, for it is only in understanding something can we elevate or overcome it.
Well, enough rambling for one day, there is work to be done!
Last night for example religion for some reason was paramount in my mind as I started to drift off. I remembered such adages as "God helps them that help themselves", and the parable of the servants and the money which goes something like "A master gave three servants each some money and instructed them to take care of it while he was gone. One went out and invested it, another used it to buy grain and plant it, while the third buried it. Upon the masters return each was called into accounting for the money they had been given, the first gave back two fold, the second was unable to give back crops because of a blight, the third gave back exactly what he was given. The master praised the two who had invested and put the money to work and rewarded them, even though the second had lost the money, the third, who only hid the money to return the exact amount, was punished." forgive any paraphrasing...
It seems to me that many of the fundamentalist beliefs are rather like the third servant. They take the coin of heaven and attempt to return it without changing it, improvement or loss. They feel that to question, challenge or add to the amount given (I am not talking about how many you add to the numbers of the church, I am talking about knowledge) is in some way forbidden, as if the holy book sprung, not from the labor of hundreds of people over thousands of years, but whole and perfect from the hand of God. When there are errors in translation, errors in usage, errors in understanding, they accept this all as whole cloth, not weaving more, not patching the holes, and not washing the stains away.
This happens of course not only in religion, but in life as well. In technical areas we have our own version of the GI-GO syndrome (garbage in - garbage out) known as garbage-in-gospel-out (I talked about this in an article back in the late 80's), that portends if it issues from a computer it must be gospel. In law we base everything on precedents, as if those in the past were smarter, more enlightened and knew more about the current situation than we do.
I believe that each person has the responsibility to learn as much as they can. We are all our own product. Many times people have accused me of being, shall I say eclectic? To which a say thanks. Having read at last estimate over 3000 or so books in my lifetime (give or take 100 or so) and hoping to read at least another 3000 before I pass into my reward, I find it gives me quite a platform on which to stand while I reach for more. Reach for more understanding. more knowledge and more insight that is. My reading reaches from technical and religious books to science fiction, historical fiction and the occasional horror or action adventure. Each book has something to teach, if you limit your reading on any topic to just one author, your horizon will be limited.
In a recent conversation someone dear to me expressed horror that I would read certain books by authors who disagreed with that persons basic belief structure. Words are only given power by the reader. I read what gives me more understanding, for it is only in understanding something can we elevate or overcome it.
Well, enough rambling for one day, there is work to be done!
Sunday, March 20, 2005
Be Careful In What You Prove
I have recently been researching scuba diving sites within the USA for a possible series of articles for a scuba magazine. Believe it or not, I do have interests outside of Oracle! One of the sites, Rock Lake, Wisconsin is of particular interest for what lies beneath its turgid waters. But if I reveal too much now it might dilute the future article. What it has brought to light is the fact that you must be careful not only in what you believe to be true but in what you prove to be true. The tales of what lay beneath Rock Lake vary from lost Atlantis to only legends. I am sure if the two camps were brought together, bloodshed would ensue as each defended their point of view. To each of the camps, what they believe is the truth.
Many people believe that truth is immutable, that what is true now is always true. However, times change, technology changes, even (especially) theology. It was not so long ago that respected scientists believed that a Doctor washing his hands was not professional, that travelling at speeds in excess of 30 miles per hour would do irreperable damage to the human frame, that travelling faster than the speed of sound would result in a crash much like hitting a brick wall, or that setting off an atomic bomb would ignite the atmosphere and annilalate mankind.
Of course all of the above has been proven incorrect. Now there are those that propose that the charished notion that the speed of light is absolute is also a myth that will be dispelled with time (believe it or not, the "warp" drive of Star Trek fame has a basis in theoretical physics, of course it requires more energy than we can currently produce, but in medevil times wouldn't all of our current technology give us a one way ticket to the witches bonfire? ) however, as much energy as we can currently produce is perhaps a far cry from as much energy as we can produce. Some go as far as to claim that some super-novas are proof that some technologies lost control of zero-point energy.
So also must we view "proofs" given of things that are acceptable incurrent technology, in Oracle and in other technologies, as only transient in nature. Watch out that the "proofs" of today don't become tomorrows old wives tales.
For example, it wasn't too long ago that separation of indexes and tables in databases was a good and accepted method for improving performance. Of course this was because otherwise they would be on the same disk platter if they weren't seperate and would conflict. Now of course with the almost universal implementation of RAID techology (rendundent arrays of independent/inexpensive disks) this becomes unneeded (sometimes, depending on the amount of data stored on each disk in the array). It could be demonstrated, when they shared a single disk, that moving indexes away from tables improved performance. Based on that proof, no longer valid, some will say that moving indexes away from tables always improves performance.
Likewise the old saw that moving to RAW devices in UNIX (raw meaning the application was responsible for IO) would result in large improvements in performance. This of course was based on the premise that all of the buffering in the OS for non-raw filesystems caused delays. Now modern file systems can be set to eliminate this buffering and journalling delays and the performance gains from raw have deminished to nearly null. Of course rebuilding the objects within the databases involved, (tables and indexes) restoring them to proper parameters that they may have exceeded through years of neglect also helped.
So now we have a new crop of experts providing proofs (sometimes limited to a single-user, small database on a laptop) that their methods are the best and no doubt their proofs will be sited long after they are useful or meaningful and their expert advice will fade into old DBA tales as new technologies and methods become the rage. This is as it should be.
I guess I am trying to say, in a rambling way, that todays sage advice becomes tomorrows old tale. We must all be aware of what the current methods are, realize when the old methods no longer apply, and gracefully accept new ways if we are to grow and prosper. However, we must also recognize when the "proper" method evolves and mutates into a "new" method, leaving the old ways to die away.
So be careful in what you prove and how you prove it. What seems clever today may come back to haunt you. You may be aplogizing several years down the road for what is right now, but not in the future. The net is an amazing place. No doubt you can find numerous places where I may have exponded on the virtues of separation of indexes and tables, on rebuilding indexes frequently or other items that have since been proved, for current versions, old DBA tales. I like others before, am not immune to time and neither is my advice.
If any paper you read is older than a year or two, I suggest you take its advice with a big grain of salt as it may be applicable only to history and not current events.
Critics love to dig up old papers, presentations and advice given and use it to bludgeon people into believing they are the only authority. Take this type of advice with a grain of salt as well. In time, their advice will be referenced, out of date and out of style.
Many people believe that truth is immutable, that what is true now is always true. However, times change, technology changes, even (especially) theology. It was not so long ago that respected scientists believed that a Doctor washing his hands was not professional, that travelling at speeds in excess of 30 miles per hour would do irreperable damage to the human frame, that travelling faster than the speed of sound would result in a crash much like hitting a brick wall, or that setting off an atomic bomb would ignite the atmosphere and annilalate mankind.
Of course all of the above has been proven incorrect. Now there are those that propose that the charished notion that the speed of light is absolute is also a myth that will be dispelled with time (believe it or not, the "warp" drive of Star Trek fame has a basis in theoretical physics, of course it requires more energy than we can currently produce, but in medevil times wouldn't all of our current technology give us a one way ticket to the witches bonfire? ) however, as much energy as we can currently produce is perhaps a far cry from as much energy as we can produce. Some go as far as to claim that some super-novas are proof that some technologies lost control of zero-point energy.
So also must we view "proofs" given of things that are acceptable incurrent technology, in Oracle and in other technologies, as only transient in nature. Watch out that the "proofs" of today don't become tomorrows old wives tales.
For example, it wasn't too long ago that separation of indexes and tables in databases was a good and accepted method for improving performance. Of course this was because otherwise they would be on the same disk platter if they weren't seperate and would conflict. Now of course with the almost universal implementation of RAID techology (rendundent arrays of independent/inexpensive disks) this becomes unneeded (sometimes, depending on the amount of data stored on each disk in the array). It could be demonstrated, when they shared a single disk, that moving indexes away from tables improved performance. Based on that proof, no longer valid, some will say that moving indexes away from tables always improves performance.
Likewise the old saw that moving to RAW devices in UNIX (raw meaning the application was responsible for IO) would result in large improvements in performance. This of course was based on the premise that all of the buffering in the OS for non-raw filesystems caused delays. Now modern file systems can be set to eliminate this buffering and journalling delays and the performance gains from raw have deminished to nearly null. Of course rebuilding the objects within the databases involved, (tables and indexes) restoring them to proper parameters that they may have exceeded through years of neglect also helped.
So now we have a new crop of experts providing proofs (sometimes limited to a single-user, small database on a laptop) that their methods are the best and no doubt their proofs will be sited long after they are useful or meaningful and their expert advice will fade into old DBA tales as new technologies and methods become the rage. This is as it should be.
I guess I am trying to say, in a rambling way, that todays sage advice becomes tomorrows old tale. We must all be aware of what the current methods are, realize when the old methods no longer apply, and gracefully accept new ways if we are to grow and prosper. However, we must also recognize when the "proper" method evolves and mutates into a "new" method, leaving the old ways to die away.
So be careful in what you prove and how you prove it. What seems clever today may come back to haunt you. You may be aplogizing several years down the road for what is right now, but not in the future. The net is an amazing place. No doubt you can find numerous places where I may have exponded on the virtues of separation of indexes and tables, on rebuilding indexes frequently or other items that have since been proved, for current versions, old DBA tales. I like others before, am not immune to time and neither is my advice.
If any paper you read is older than a year or two, I suggest you take its advice with a big grain of salt as it may be applicable only to history and not current events.
Critics love to dig up old papers, presentations and advice given and use it to bludgeon people into believing they are the only authority. Take this type of advice with a grain of salt as well. In time, their advice will be referenced, out of date and out of style.
Wednesday, March 16, 2005
Call me Abused
Just finished doing a RAC class on Oracle9i RAC. During the class we installed Oracle RAC. Let me tell you, installing RAC on Oracle9i, version 9.2.0.6 is not the funnest thing I have done in a long time. Feel like a horse that was rode hard and put down wet. When I first started working with 9i and RAC the install was a bit convoluted. However, it has gotten much worse! Between missing directories, missing links, needing to install the universal installer, having the universal installer mess up the JRE, well, you ge the picture.
Compared to this "terminal" 9i release, 10g RAC install is a snap. But enough about that. Some comments on classrooms. Always teach from the front, it allows eye contact and allows you to see the expressions on the classes faces. I have had to teach three times from the back of a room, in each case I left feeling that I didn't do a good job, usually, so did the class. Eye contact and being able to see if the class understands key points is critical to good teaching.
Also, if the class uses software, such as RAC, make sure it is up and running before the class begins (unless the major part of the class is the install). The other times I have felt that the class got less from the class then they should have when I had to wrestle with a balky install. No matter why the software doesn't install, be it poor documentation, bugs or just bad karma, this will rub off on the classes opinion of your expertise.
A final observation, try to reduce any powerpoint slides to just talking points and needed diagrams. If you have a whiteboard, use it. Classes like the hands-on approach. As tempting as it is sometimes, especially when facing outside issues such as a balky install, don't just read the slides! I find myself falling into the trap when I have not had sufficient time to prepare for the class (it usually takes 4-6 hours per hour of class time to prepare materials.) Usually this means I put too much on the slides. By just putting bullet points for the topics on the slides, you can avoid this trap.
Well, that is all for now, talk to you later.
Compared to this "terminal" 9i release, 10g RAC install is a snap. But enough about that. Some comments on classrooms. Always teach from the front, it allows eye contact and allows you to see the expressions on the classes faces. I have had to teach three times from the back of a room, in each case I left feeling that I didn't do a good job, usually, so did the class. Eye contact and being able to see if the class understands key points is critical to good teaching.
Also, if the class uses software, such as RAC, make sure it is up and running before the class begins (unless the major part of the class is the install). The other times I have felt that the class got less from the class then they should have when I had to wrestle with a balky install. No matter why the software doesn't install, be it poor documentation, bugs or just bad karma, this will rub off on the classes opinion of your expertise.
A final observation, try to reduce any powerpoint slides to just talking points and needed diagrams. If you have a whiteboard, use it. Classes like the hands-on approach. As tempting as it is sometimes, especially when facing outside issues such as a balky install, don't just read the slides! I find myself falling into the trap when I have not had sufficient time to prepare for the class (it usually takes 4-6 hours per hour of class time to prepare materials.) Usually this means I put too much on the slides. By just putting bullet points for the topics on the slides, you can avoid this trap.
Well, that is all for now, talk to you later.
Tuesday, March 15, 2005
It is Totally Amazing...
I will begin blogging with a few thoughts on the time and energy other "experts" put into questioning everything said. I find it amazing the folks such as Howard J. Rogers can spend so much time and energy beating dead topics to death. Most of us have moved beyond arguments about index rebuilding and coalescing. I suggest them when it is indicated that it will help, it is one tool in a tuning experts arsenal. When I suggest a rebuild or a coalesce of an index in Oracle database systems it is only after a complete analysis points to the index as a problem.
Business must be slow down under for Howard to have so much free time. I have to grab a few minutes between running for the plane, working with customers all across the country and trying to keep up with my remote monitoring and tuning committments to swat at this annoying gadfly.
As to the whole debate (well, at least from Howards viewpoint it is a debate, for me it is just a tool to use when indicated) about reordering a column order in a concatenated index, again, Howard and others seem to feel that once an index is created it is sacred and can't be touched. Obviously they have never worked with a poorly crafted, poorly indexed third-party or custom generated application, for that matter, they must have never worked with Oracle's own Applications. I have seen applications where a table had 29 indexes. If I followed Howards way of thinking each would be a sacred object that I shouldn't touch because obviously the need for each was carefully considered and it would bring down the entire application to change it. Hog wash.
It merely shows that Howard spends too much time with theory and not enough in real-world tuning situations. I have been at over 24 client sites in the last 6 months doing tuning, optimizing and database evaluations. I find things that work and apply them as needed. My job is to help an ailing database back to health and to improve peformance of client applications. If this means that I drop, rebuild or otherwise change an index, then that is what it means. Heaven forbid, I even suggest adding an index occasionally!
Business must be slow down under for Howard to have so much free time. I have to grab a few minutes between running for the plane, working with customers all across the country and trying to keep up with my remote monitoring and tuning committments to swat at this annoying gadfly.
As to the whole debate (well, at least from Howards viewpoint it is a debate, for me it is just a tool to use when indicated) about reordering a column order in a concatenated index, again, Howard and others seem to feel that once an index is created it is sacred and can't be touched. Obviously they have never worked with a poorly crafted, poorly indexed third-party or custom generated application, for that matter, they must have never worked with Oracle's own Applications. I have seen applications where a table had 29 indexes. If I followed Howards way of thinking each would be a sacred object that I shouldn't touch because obviously the need for each was carefully considered and it would bring down the entire application to change it. Hog wash.
It merely shows that Howard spends too much time with theory and not enough in real-world tuning situations. I have been at over 24 client sites in the last 6 months doing tuning, optimizing and database evaluations. I find things that work and apply them as needed. My job is to help an ailing database back to health and to improve peformance of client applications. If this means that I drop, rebuild or otherwise change an index, then that is what it means. Heaven forbid, I even suggest adding an index occasionally!
Subscribe to:
Posts (Atom)
