I was recently requested to review a new book "Middleware Management with Oracle Enterprise Manager Grid Control 10g R5" by Debu Panda and Arvind Maheshwari . I received a review e-copy of the book and was pleasantly surprised when I went through the book, it is a very good introduction for all the people who are working with Oracle Fusion Middleware and want to use Oracle Enterprise Manager Grid Control to manage most of the stack.
After a brief explanation of installing Grid Control, including monitoring basics, the book delves into monitoring and managing Oracle WebLogic Server, Oracle Application Server, Oracle Forms and Reports Services and Applications. It then also looks at the monitoring of BPEL process manager and BPEL processes, the monitoring of the Oracle Service Bus (OSB) and OSB services, managing the Identity Manager Suite, the Coherence Cluster, and also non-Oracle middleware like Apache, Tomcat, JBoss, IBM Websphere, and Microsoft middleware.
The book also has a chapter on the new Application Diagnostics for Java (AD4J) product and Composite Application Monitor and Modeler, and how to use these products to diagnose Java applications, and monitor and diagnose composite applications respectively.
As a surprise bonus, the book has a very interesting chapter on Building your own Monitoring Plug-in. The Sun Java Web server is used as an example, and the steps to build a simple monitoring plug-in for this web server are outlined. This is followed by another good chapter on Best Practices for Managing Middleware Components using Enterprise Manager.
All in all, a very useful book for Middleware administrators who are using Oracle Enterprise Manager Grid Control, or for those who want to know how Enterprise Manager is handling the monitoring and management of such products. Well done and a good practical guide.
Embedding Vectors vs. Vector Embeddings
2 weeks ago
13 comments:
I am playing around with OEM Grid R5.
We have a lot of Development and Production DBS and associated applications.
Now I think to my limited knowledge there is a BIG problem with notification rule subscription.
I do not know a way to assign a subcription to a Group.
So inidividual administrators needs to be subsribed to a notification rule eplicitly. This is not good. Lot of redundant work.
Any thoughts on this ?
Yes, notification rules need to be subscribed to by individual admins. This is because each admin needs to be sure of what they are receiving. You can circumwent this by creating an administrator for the whole group such as "BillingDBAGroupAdmin" and have it used by the group of DBAs.
However this may not be suitable for security compliance - the admin must log in individually and not as a group.
I have a very very very .....
Basic requirement.
I seem to be at a loss why OEM would make it so difficult.
I am the only DBA and I have pager.
We have production system and development systems.
I need to get pager notifications on only my proudction systems.
Now for such a basic requirement.
I create two administrators
dba_admin and dba_pageradmin
dba_pageradmin has the pager email
dba_admin has dba email
sysman has out of box notification rules.
I have created two groups in OEM
production group and dev group.
Now the most painful part.
For dev group I subscribed to out of box notification and associated dba_admin with these notifications.
Now I cannot subscribe dba_adminpager administrator or even the out of box notification already used by dev group to production group.
There is a BIG missing link between OEM groups and OEM administrators.
If only we could attach admins to groups this would solve the problem.
My painful solution :
Duplicate all out of box sysman notification rules and then assign it to production group and subcribe to dba_pageradmin.
Please correct me , If I am doing the wrong this.
How would you solve such basic need. surprsingly none of the BOOKS or manuals even discuss this simple case.I am surprised.
Its definitely got to do with my ignorance or am I the only one lost
I hope I explained my case well.
Login in as sysman, since this is a super administrator, you can set up the notification rules for other EM administrators. Make the rule as public.
The following is from http://download.oracle.com/docs/cd/B19306_01/em.102/b40002/notification.htm#sthref982
"When you specify the notification rule properties, check Make Public in the General page if you want other non-privileged users to be able to view and share that rule. For example, it allows other administrators to later specify that they should receive e-mail for this rule."
Please do refer to the EM manuals regularly, and you can also raise an SR to clear any doubt provided you have a valid Oracle support contract for the Oracle Enterprise Edition.
Thank you Sir.
You mentioned as per the manual :-
Login in as sysman, since this is a super administrator, you can set up the notification rules for other EM administrators. Make the rule as public.
This wont work .
I have say for example a notification rule of tablespace full - 90 % warning.
This rule is susbcribed to both Production group system and development group system.
Admins DBA and DBA_pager can subscribed to this rule but since it is attached to both the Prod and dev group. I dont want pager for dev notification.
I only want pager for Prod notification of tablespace full.
Now to this I have to duplication the tablespace notification rule for Prod and call it say Prod_tablespace_rule and then subsribe this to Prod group and dba_pager admin.
You see I am duplication the rules due to lack of associations between
a group and an admin.
Still the question remains.
Why should we need to duplicate the same notification - rules for Dev and Production just to filter out Production notifications to be sent to dba pager as well.
Do you agree with my solution.
Do you see any other way of doing this.
This does not make any design sense.
There should be a link between
Groups and Admins so that we can tie up a group to an admin
admin M : N groups . Relationship.
Now You tell me havent you come across this situation when you have implemented so many systems with EM GRID.
Why to duplicate the same rules for Production Group systems just to associate a pager
This seems to be such a basic requirement and a very bad solution. May be there is something better I am not aware of
Any suggestions,corrections welcome.(I hope I was able to make you understand the problem in the original post).
Anonymous (whats your name?),
You are definitely doing things in a strange way, not many people would have a separate admin just for pagers. I feel since you have complicated the issue, you need to have the duplication of notification rules.
If you keep it simple, it will not be necessary. I advise you to rethink your setup.
Hi,
Yes I agree it is complicated because I dont find any other way to do this.
As I mentioned I am the only DBA , I have my email and I have a pager.
I could not find anyway to assign multiple email addresses to notification rules without creating a new admin and assign it an email address.
So it is 1:1 (or 1 :M see below )for admin and email addresses.
Now I dont want to be paged for dev databases.
If you see the Preferences--->general tab
"
These addresses are used to send notifications to you. You can specify multiple addresses if you want to be notified in different ways, and the format to use for each address. Later on, you will need to define a Notification Schedule before any e-mail notifications can be sent to you.
"
there you can give multiple emails. But they can be customized as per the schedule only not as per the group Prod/Dev to which notifications have been subsribed.
I keep asking myself and others again and again, And no one has yet answered.
Very simple request.
I need to enable pager notification only to my Prod databases ( There are hundreds of Prod DBs , so I created a prod group and assigned all Prod DBS here.)
Sir you mentioned
"
If you keep it simple, it will not be necessary. I advise you to rethink your setup
"
Sir can you tell me how would you solve/implement this basic requirement.
I am really shocked , I read all the GRID books available from Oracle press . Dont know why they do not discuss this basic case.
Sometimes I think I am Crazy doing things the wrong way, But I am willing to learn If you show me another way :) Hence I landed up here after googling around
I raised this question with Oracle and I got the answer:
Yes, one solution would be to create another set of rules for the production systems and have the dba_pageradmin subscribe to these rules. So you would have a separate set of rules for production vs development.
The other alternative is to control this via privileges, i.e. have the dba_pageradmin only have privilges on the production targets/group and do not grant it any privileges on the development targets/group. Similarly, grant privileges to the dba_admin user on the development targets/group only and do not grant it any privileges on the production targets/group.
Then in the same notification rule, you can put the 2 groups (development and production) and have the 2 users subscribe to the rule.
When an alert triggers on the production target, since only dba_pageradmin user has privileges on the target, he can see the alert and receive pager notification for the alert. The dba_admin user will not be able to see the alert since he has no privileges on the target and thus will not receive notifications for it.
Similarly, when an alert triggers on the development target, only dba_admin will see the alert and get email notifications for it; dba_pageradmin will not get notifications for it since he cannot view the target.
Hope this satisfies your query.
Simon,
I would like to point out at this stage that viewing the alerts in the EM Console is free but using notifications require a license. If it is for the database targets, then you would need to license the Diagnostics Pack.
Please make sure your company has a valid licence for the Diagnostic pack for all the production and test databases you are geting your notifications from.
Regards,
Porus.
Thank you so much for your help on this.
I came to the right place.
So it makes sense now.
As I said earlier. This is such a basic requirement and I dont know why has anybody not raised it before in any forums.
Regarding the License. I am still evaluating OEM product. Its not even in development. I have all my test environments to simulate production and dev settings.
I am learning it as a personal tool. Need to evaluate and get comfortable with it before I can propose and stand by the tool.
I am doing the technical review.
Thanx for clearing a BIG Configuration Snag.
I wish Oracle makes this basic requirement simple in future releases.
We also need the ability to link/subscribe an admin to groups in M:N relationship. Just thinking loud.
Great to hear Simon.
Regards,
Porus.
Vow I see you have a new book out.
I am going to recommend it to the whole world of Oracle Techies I know.
Does the new book deal with the simple basic Problem which I had about configuring Pager for Production notification ?
Sometimes the solution is so simple yet very elusive.
One more experience I would like to share with you since you are a very very gridi ( Not greedy) guy.
Installation of 10.2.0.5 on Linux 64 bit using existing Database 11grel 2 database option.
I think Oracle never tries to test out things on its own end. they wait for custemers to come up with bugs issues and then they wake up.
I had to come up with my own workarounds to succesfully install OEM gRID. I do not know why it should be so difficult or rather Oracle makes the installations very difficult.
The meatlink note :-
How to Install Grid Control 10.2.0.5.0 on Enterprise Linux 4 Using the Existing Database (11g) Option [ID 793870.1]
Does not work for 64 bit. It only works for 32 bit OLE5.
Oracle has acknowledged there is a
bug BUG:7483221 - CONFIGUREGC.PL IS FAILING WITH INVALID PASSWORD FOR SYS
with no resolution for 64 bit OLE5.
It was so frustrating , I had to do my own R&D to come up with a solution.
Why should Installation be an R&D thing ? Shouldnt it be well documented ?
If not sure why release the docs to customers in metalink to undergo lot of misery.
( Oh I had lot of similar stories. take for example upgrading 9i dataguard to 11g its open secret Oracle does not know how to do it. From 9i to 11g they changed the archive log format and that makes it tricky and challenging. I again had do it R$D for this and come up with my own solution. Oracle tried it for 2 months and I finally gave up on them )
It is very easy to put those documents but does anyone in Oracle ever try it before documenting.
We are very practical hands on DBAs so we catch the issue right away.
Thanks Simon. I will let you know when published. Be sure to recommend the book to all your friends and colleagues.
The book doesnt discuss your particular issue, but goes into a lot of practical database administration techniques using Grid Control, for example, patching your databases, forming an effective RMAN strategy for backup, and how to create and manage Data Guard standbys. Have a look at the table of contents on the book page link.
Yes, there is R&D involved in the DBA job. But that is what makes it so interesting. If everything worked perfectly, there would be no challenges.
Post a Comment