This discussion is archived
1 6 7 8 9 10 11 Previous Next 163 Replies Latest reply: Oct 22, 2009 3:23 PM by Hoek Go to original post RSS
  • 105. Re: Index rebuild
    ji li Pro
    Currently Being Moderated
    Thank you Richard. Excellent reply.
    I'll keep this for future reference...
    I certainly consider all four of you (yourself, Jonathan L., Tom K, and Don B.) as the experts.
    Thank you for your comments.

    ji li
  • 106. Re: Index rebuild
    706417 Explorer
    Currently Being Moderated
    Hi Randolf,

    I don't think that the SQL Test Case Builder can be meaningfully compared to what has been referred to as a test case by DKB.

    SQL Test Case Builder is a bit of Oracle software designed to allow Oracle Support to get a system at their end looking and feeling like your system, in order to reproduce your error in a like-for-like system. I haven't used it so can't comment on its worthiness.

    The fact that such a tool exists proves, surely, that Oracle recognizes that each customer system is as different as a fingerprint. So Don is right: test cases are only 100% guaranteed to be useful for one's own system.

    My system disk, network, cpu, platform, user load, OS level, RAM, storage, code, database params, database release, 3rd party software, Business rules etc. are not like anyone else's. So, even a well-intentioned "test case" on a plain vanilla system is hardly worth the effort of looking at - it's nothing like my system.


    Regards - Don Lewis
  • 107. Re: Index rebuild
    706417 Explorer
    Currently Being Moderated
    +(Not that the system sounds big enough to need 4-node RAC)+

    Size has nothing to do with RAC/non-RAC.

    If the business is likely to suffer badly if nobody can work on the database (i.e. a node dies), then having other nodes saves the day. Similarly, splitting logical entities of work across nodes can help protect each from the others.

    I know of a big company that has enormous numbers of transactions per second, gargantuan everything, but no RAC. They have gone for the "Amazing Hardware Rules the World" approach. It works for them and they lead the world in what they do.

    Conversely, I know of a small (almost a Mom & Pop compared to most places I have worked at) business that has a 4-node RAC set-up because being available is its lifeblood and they can't afford the "Hardware Rules" approach.



    Regards - Don Lewis
  • 108. Re: Index rebuild
    635471 Expert
    Currently Being Moderated
    >
    My system disk, network, cpu, platform, user load, OS level, RAM, storage, code, database params, database release, 3rd party software, Business rules etc. are not like anyone else's. So, even a well-intentioned "test case" on a plain vanilla system is hardly worth the effort of looking at - it's nothing like my system.
    There are obviously different degrees to which this is true though.

    It is sometimes very easy to put together a script to demonstrate a particular feature or problem. I recall putting together a test case to demonstrate that partition exchanges could cause bitmap index corruption (9iR1 I think), and a companion script to provide a workaround. It took maybe five minutes once we had a rough idea of what the cause could be. Now that issue was 100% independent of system disk, network, cpu, user load, OS level, RAM, storage, code, database params, 3rd party software, Business rules etc. for reasons that were very obvious to us.

    And the important part is that the script could be used on other systems to see if they had the same problem.

    We sent the script to Oracle support (it was of course completely free of any proprietary information) and it demonstrated the problem to them. We could also apply an Oracle-supplied fix to the data dictionary, and the script proved that that worked as well. When we upgraded we didn't have to rely on some airy-fairy previous experience that partition exchanges could cause bitmap index corruption ... we has test case for the problem that demonstrated that it was fixed.

    The fact that there are some effects that are very difficult to demonstrate in a test case doesn't mean that all test cases are worthless by any means. Multiuser tests are more difficult than single user, reproducing a memory-related bug is often very tricky (but it can be done). But a great many problems can be demonstrated with a script that can then be used on any system to see if it has the problem.

    Competent DBA's and developers are doing this stuff all the time.
  • 109. Re: Index rebuild
    hans forbrich Oracle ACE Director
    Currently Being Moderated
    Don Lewis wrote:
    So Don is right: test cases are only 100% guaranteed to be useful for one's own system.
    Interesting.

    Are you implying:
    - "Your experience is not 100% guaranteed to be valid on a different system"
    - "Your experience is 100% guaranteed to be invalid on different systems?"
    - "Your experience is only 100% guaranteed for one's own system - assuming conditions do not change"
    - "Test cases can never provide any form of experience"

    Edited by: Hans Forbrich on Oct 15, 2009 8:53 AM - reformatted/expanded for clarity
  • 110. Re: Index rebuild
    706417 Explorer
    Currently Being Moderated
    "But a great many problems can be demonstrated with a script that can then be used on any system to see if it has the problem."

    I know what you are saying, I do, but my system != your system.

    I know that probably sounds deliberately awkward, on my part, but it isn't.

    If Fred says, "I just ran the attached script and it shows that deleting from a table with more than 1M rows on a Wednesday causes core dumps. All the proof is attached.", then, naturally, I'm interested in what Fred has said. But, I wouldn't be in the least bit surprised if Fred's test case failed to show the same results on my system. He might have params set that I don't, and vice versa, plus any other number of differences.

    I have Jonathan's Fundamentals book. Credit where credit's due, it's interesting (if often daunting), but something that he says in the book shows, I think, just how utterly idiosyncratic any system can be - my emphasis:

    "So if your experience contradicts my claims, you may have a configuration that I haven't
    seen—I’ve only got through a few hundred databases in my lifetime, and *there must be millions*
    *of combinations of configuration and data distribution details that could make a difference*. In
    most cases, the download includes scripts to allow you to reproduce the test cases in the book—so
    you can at least check whether my test cases behave as predicted when run on your system.
    Whatever the results, you *may* get some clues about why your observations differ from my
    observations."


    In other words: his "test cases" are only suitable for one, very specific set-up.


    Regards - Don Lewis
  • 111. Re: Index rebuild
    6363 Guru
    Currently Being Moderated
    Don Lewis wrote:

    My system disk, network, cpu, platform, user load, OS level, RAM, storage, code, database params, database release, 3rd party software, Business rules etc. are not like anyone else's.
    What would be interesting is how this leads to Oracle creating indexes with different structures, behaviors and algorithms, and why these differences only seem to kick in certain real world databases seen by one person, and not all the other databases that everyone is running their meaningless scripts on.

    Maybe it because all these special real world databases seem to be both heavily used by many users yet have a surprisingly luxurious amount of down time in which to regularly rebuild indexes.
  • 112. Re: Index rebuild
    MarcinP Oracle ACE
    Currently Being Moderated
    Don Lewis wrote:

    I know what you are saying, I do, but my system != your system.
    Hi Don,

    This is very important point. Yes every system is different but if you have a well defined test case
    you can run it on your system and compare results.

    >
    In other words: his "test cases" are only suitable for one, very specific set-up.
    And if your results are similar to author of test case it can be very similar system problem/bug/etc
    and you can read a solution or workaround - if of course author of test case deliver it.



    regards,
    Marcin Przepiorowski
  • 113. Re: Index rebuild
    635471 Expert
    Currently Being Moderated
    Don Lewis wrote:
    In other words: his "test cases" are only suitable for one, very specific set-up.
    Well, not really one. For the examples in the book, I'd say a great many. But there may exist configurations that do differ.
  • 114. Re: Index rebuild
    chris_c Journeyer
    Currently Being Moderated
    Don Lewis wrote:
    I know what you are saying, I do, but my system != your system.
    My opinion is thats why i need a test case, i need some way to validate a claim before i perform full scale testing i can take a well designed test case and run it on a system I control and can configure, if i don't get the result expected i can discard the claim or investigate why i see a different result. If there are a number of different options to resolve the problem I can run multiple small scale tests prior to progressing to full testing. This way I can save my clients time and money as I have less tests to perform in a full scale enviroment.
    Without a test case I'm left trying to get approval to test something that is based on 'What some bloke on the internet said' which is kind of hard.
  • 115. Re: Index rebuild
    hans forbrich Oracle ACE Director
    Currently Being Moderated
    In addition - a properly thought out and document test case also describes the assumptions, including the configuration. Which allows one to use the test case to narrow the total set of possible solutions.

    Of course, a bank of informal test cases (aka experience) helps this as well. But, due to the lack of documentation and formality, only permits the experienced person (person who knows the assumptions) to use that experience.
  • 116. Re: Index rebuild
    Randolf Geist Oracle ACE Director
    Currently Being Moderated
    Don Lewis wrote:
    SQL Test Case Builder is a bit of Oracle software designed to allow Oracle Support to get a system at their end looking and feeling like your system, in order to reproduce your error in a like-for-like system. I haven't used it so can't comment on its worthiness.
    I always wonder how people come to judge something that they've never used themselves. If you had used it yourself (suggestion: a test case for the SQL Test Case Builder?), you might have found out that it's not a bit of software for the Oracle Support but a PL/SQL package that you can use yourself to automatically gather all information that Oracle thinks is relevant to automatically generate a reproducible test case for a particular SQL statement (which is a specific, but important purpose, since many issues are caused by single SQL statements).

    It can be used to reproduce e.g. a Production issue encountered with a SQL statement in a Development environment by generating and exporting the test case in Production and importing it into another environment. It might come handy when dealing with Oracle Support, but nowhere it is said its only purpose is for Oracle Support cases.

    Saying that test cases are useless in general because every system is different I think misses the point and your "Fred" example just demonstrates when a test case might be really useless: When the test case is not properly documented.

    It all depends on how accurately you describe the test case, and that is the main purpose of the SQL Test Case Builder - it automates to gather all information that Oracle considers to be relevant to reproduce a SQL statement behaviour in a different environment.

    However in many cases a reproducible test case can be generated by stating a rather limited number of configuration items and without the help of such tools like the SQL Test Case Builder, and using this configuration it will be reproducible on almost any Oracle system (no matter what your "system disk, network, cpu, platform, user load, OS level, RAM, storage" might be).

    The nice thing is that even if you fail to reproduce the issue, it tells you something: That there is probably a difference between your system and the source system. Once you find out what makes this difference this might provide another clue what the root cause of the issue really is and how things work.

    Understanding how things work allows to come up with better solutions and proposals.

    Even if you open an SR, Oracle Support always asks you the same questions: Can you reproduce the issue at will? Can you come up with a test case that is as generic and simplified as possible? I've encountered it more than once that if the issue was not reproducible that the SR was simply closed for that reason.

    After all, a computer is supposed to behave in a deterministic way; it just depends on the different inputs. Use the same inputs and you're supposed to get the same output. The hard part might be to gather what the relevant inputs are.

    Regards,
    Randolf

    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/

    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/
  • 117. Re: Index rebuild
    706417 Explorer
    Currently Being Moderated
    No. Because unlike a test case, I have a human brain.
  • 118. Re: Index rebuild
    jgarry Guru
    Currently Being Moderated
    Don Lewis wrote:
    No. Because unlike a test case, I have a human brain.
    Would there be a split-brain problem here?
  • 119. Re: Index rebuild
    706417 Explorer
    Currently Being Moderated
    Hi Chris,

    I have been thinking about what you said. It's true: we all, from time to time, are asked to predict the future using test cases:

    "We will need more databases next year. We want to use AIX, though, not Linux. Oh, and we want to Data Guard it, too. And we want to use Advanced Compression. And the data size is going to be twice what we have now. We'll be using Acme SAN, not Snibbo Filer. Go away and predict the impact, financially and otherwise."

    Not that far-fetched a request. To research that fully and meaningfully cannot be done. The best you can do is get a close approximation via getting a vendor to do the usual parlour tricks, read-up on the Web, use whatever figures you have, and then make an educated (perhaps very educated) guess, backed up, naturally, with oodles of test cases. The variables are too numerous and unpredictable. It really just ends up being a mix of truth, hope and guesswork.

    The only, only way to prove the theory is to actually do it for real on your system.

    Has nobody ever been involved in a User Acceptance Test, ironed out the problems, re-run with 100% success, and then seen it crash and burn in the production release because Terry in the Network Team made "that little change to the DNS entries", or Development made a teensy-weensy little modification to a single line of code, just after UAT finished and outside of Change Control, or (my favourite) an Oracle Home throwing a wobbly during a release because the OH cloning is buggy and Prod. and UAT are NOT running from identical OHs after all! Etc., etc., etc. And that's on Your Own System! There! There are a few reasons why your fantastic Test Case that was to shake the world is, in fact, worth nothing. And all written and tested by you on your own system!

    So, any test case is also subject to such variables and unknowns. It simply cannot be the case that an experiment on one system will definitely pan-out the same way on another system.

    To recap: Oracle RDBMS is not science. It is a big bunch of software. It has bugs and stupidities in it. It changes - often. It is not sane to expect it to behave like gravity, light, chemicals, planetary orbits, etc., because it's been written by humans and each real-life system differs from all others.

    Someone else's test cases are of interest, sure, but do not have meaningful relevance to my system. Only my test cases have meaningful relevance to my system. Demonstrating anything on a pared-down Oracle database on a laptop and suggesting that a big fat multi-terabyte, SANned-up, Infinibanded, RAC-enabled, you name it system, with its attendant Oracle-supplied params fixes and tweaks is likely to behave in an identical manner is a bit unconvincing.


    Regards- Don Lewis
1 6 7 8 9 10 11 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points