1 2 Previous Next 19 Replies Latest reply on Dec 27, 2013 7:07 PM by jgarry Go to original post
      • 15. Re: Performance Monitoring Dashboard


        • 16. Re: Performance Monitoring Dashboard

          Krishna wrote:



          You seem to think that the objections to your plan have to do with some sense of personal insult or "disrespecting" oracle - either the company or the product.  I assure you nothing is further from the truth.  It is about efficient and best use of your time.  As I said before, if you are dead-set to pursue this project, knock yourself out.  But is is my considered opinion that your time would be better spent getting "comfortable with"  the products that are already available.  Certainly, if I were the person signing your pay check I would tell you in no uncertain terms that I would not want you spending your time on this project.

          • 17. Re: Performance Monitoring Dashboard

            Just because you have got an answer on another forum that  X language is better and Y metric is useful doesn't mean your thought process can be validated as correct. It is just a waste of time since you, as a team of 5 dba's can't possibly make a tool that's going to match with a product that's being made by many many developers and is getting enhanced almost with every update. We haven't asked you to try out any 3rd party product(as you have named) since doing that is also going to under-value Oracle's own EM. But it seems like that you are hard-bend to go on this route only, well nothing further can be suggested in that case. As I mentioned in my other reply, I have seen it happening far too many time that people think that their own solution would be better and cheaper than the Oracle-supplied one only realizing at a very later stage and after paying a hefty penalty that they were wrong.


            Good luck!



            • 18. Re: Performance Monitoring Dashboard

              That single answer was helpful.  Perl is used by Oracle because of its cross-platform characteristics.  In fact, if you look around your system, you may see perl scripts for starting OEM and other tools.  OEM uses java.  So perl isn't the best.  Or is java the best?  From what I've seen, it often uses way more resources for OEM than it should, and in some cases has memory leaks.  So java isn't the best.  So that single answer wasn't helpful.


              "It depends on how you fetch data, how much data is being fetched, how frequent it will be executed."  This is very perceptive.  Especially the first two words.

              "Monitoring scripts will be executed every 10-15 minutes. "  OK, now that is just pulled out of a hat, full of rabbit droppings.

              "This thing depends on nature of script and what you are monitoring."  Well yeah.  It depends.

              The important point you seem to be missing is that these tools are to make your job easier and more efficient.  Simply automating what you already do may or may not have that effect.  If you are asking the wrong questions, you may never get to the right answer.  That is quite common.  The thing about the commercial tools is they are very generalized, and so happen to help many situations.  One needs to understand the underlying concepts to really utilize the tools, and especially to understand when the tools lead down a garden path - even OEM can give bogus advice, that's why one does not depend on GUI tools (and I go further - if you look at some of the code in sqlarea, it's just awful).  Writing your own tools on top of your own scripts may be worthwhile if the underlying scripts are good.  But how do you know that?  And what does the business do when staff changes?  "Not Invented Here" syndrome is a serious problem at many places.

              In case I've given the wrong impression, the dbconsole perf screen is a major help to our work, I highly recommend the few dollars (compared to five dba salaries!) it takes to get proper licensing, regardless of it's flaws.  Oh, did you say you have standard edition?

              • 19. Re: Performance Monitoring Dashboard

                For a service provider, there may be marketing considerations separate from actual technical validity - "Oh, look at our pretty dashboard, it lets us know everything to serve you better!  We're all cloudy!"  Then they can just run scripts and/or be dependent on squawks from users as the reality may be.  A service bureau may also want to hit up SMB's that aren't well served by (or have active hatred for) Oracle's marketing model.  Who doesn't dream of building up a remote dba business and selling out for millions to some dumb, er, rich, er... oh, never mind.

                1 2 Previous Next