Thanks for your response John. Iâll have to dig up the document, but we found that FM added the requirement for bidirectional traffic on 3872. Gary is right in the case of a regular OEM configuration. We have used that for a while.
Of course we could be missing somethingâŠ
Steve
From: Norman, John A [mailto:***@nationwide.com]
Sent: Tuesday, October 30, 2018 2:13 PM
To: Givens, Steven <***@fnni.com>; 'Jay Hostetter' <***@gmail.com>
Cc: 'oracle-***@freelists.org' <oracle-***@freelists.org>
Subject: [External] RE: RE: RE: Re: Rapid Home Provisioning vs Database Fleet Maintenance
I discussed this with Gary Henderson. He says when you install OEM, you have the option to select a different port besides 3872. The installation defaults to that port, but you donât have to use it.
Also, traffic to that port should be inbound only. To clarify, traffic from the OMS to the agent is via the agent port (3872), but traffic from the agent to the OMS is via the upload port (typically 4900)âŠso not bidirectional.
Thanks,
John
From: Givens, Steven [mailto:***@fnni.com]
Sent: Monday, October 29, 2018 11:05 AM
To: Norman, John A <***@nationwide.com<mailto:***@nationwide.com>>; 'Jay Hostetter' <***@gmail.com<mailto:***@gmail.com>>
Cc: 'oracle-***@freelists.org' <oracle-***@freelists.org<mailto:oracle-***@freelists.org>>
Subject: [EXTERNAL] RE: RE: Re: Rapid Home Provisioning vs Database Fleet Maintenance
Nationwide Information Security Warning: This is an external email. Do not click on links or open attachments unless you trust the sender.
________________________________
Iâm curious if anyone else has run into the architecture issue we have run into while trying to implement Fleet Maintenance? FM requires bidirectional traffic over port 3872, which our InfoSec group will not allow. We havenât found any settings to redirect traffic over a different port.
Thanks,
Steve
From: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> [mailto:oracle-l-***@freelists.org] On Behalf Of Norman, John A
Sent: Tuesday, October 23, 2018 2:30 PM
To: Jay Hostetter <***@gmail.com<mailto:***@gmail.com>>
Cc: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Subject: [External] RE: Re: Rapid Home Provisioning vs Database Fleet Maintenance
Jay,
It was a combination of self-learning (reading Oracleâs documentation for Enterprise Manager Lifecycle Management Administrator's Guide), and also a great working relationship directly with the OEM development team. We have been a beta tester for this product, more or less. This has given us the ability to share our issues directly with the OEM team and receive fixes/updates more quickly.
We are still integrating some features of Fleet Maintenance into our provisioning and patching processes. But what we have integrated so far has drastically reduced the amount of work that we used to do when we were provisioning and patching manually.
Thanks,
John
From: Jay Hostetter [mailto:***@gmail.com]
Sent: Tuesday, October 23, 2018 2:14 PM
To: Norman, John A <***@nationwide.com<mailto:***@nationwide.com>>
Cc: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Subject: [EXTERNAL] Re: Rapid Home Provisioning vs Database Fleet Maintenance
Nationwide Information Security Warning: This is an external email. Do not click on links or open attachments unless you trust the sender.
________________________________
John,
I attended this session. Your team did an excellent job. Did you folks learn on your own, attend training, or engage Oracle consulting in order to learn how to use this feature of EM? Patching is one of our biggest pain points at the moment.
Thank you,
Jay Hostetter
Sent from my iPhone
On Oct 23, 2018, at 3:54 AM, Norman, John A <***@nationwide.com<mailto:***@nationwide.com>> wrote:
Our company uses Fleet Maintenance for Oracle Home provisioning and Database Patching. We plan on using it for Database Upgrades too in the next year.
Gary Henderson and Vaithianathan Soundararajan presented on our companyâs use of Fleet Maintenance yesterday at OOW. Hopefully, you were able to attend their presentation.
The actual patching process runs roughly 6-10 minutes per database for us (would be quicker, but patching the OJVM component requires bouncing the database to put it in upgrade mode, and bouncing it again after patching is complete to open it read/write).
We have well over 1,000 databases, and patch each database at least twice per year. What used to take an entire staff of 10 DBAs is now handled by 1-2 DBAs.
Thanks,
John
From: oracle-l-***@freelists.org<mailto:oracle-l-***@freelists.org> [mailto:oracle-l-***@freelists.org] On Behalf Of Pecoraro, Michael
Sent: Tuesday, October 23, 2018 2:16 AM
To: oracle-***@freelists.org<mailto:oracle-***@freelists.org>
Subject: [EXTERNAL] Rapid Home Provisioning vs Database Fleet Maintenance
Nationwide Information Security Warning: This is an external email. Do not click on links or open attachments unless you trust the sender.
________________________________
Iâm curious to know how many are using Rapid Home Provisioning in their organization and how you are using it. Have you compared RHP to Database Fleet Maintenance? Are you considering using Database Fleet Maintenance to patch and upgrade your databases over RHP?
We have been using RHP for roughly the past year. In our environment, RHP is used mainly to provision Oracle Homes for our databases and to create the databases (CDBs). Our original plan was to use it for database patching as well. The creation of Oracle Home images and working copies has worked well overall across our various clusters. However, the performance of the working copy creation is not good. The process runs over 90 minutes in a four node cluster. It runs much longer in our larger clusters. The database creation process works, but in some cases we wish we had more customization options. The database patching (ârhpctl move databaseâ) has been very buggy in our environment. Given the various issues we have with RHP, we are considering a switch to Database Fleet Maintenance.
Iâm at OOW this week. If youâd like to meet up to discuss it further, send me a message.
Thanks,
Mike
---
Michael J Pecoraro
University at Buffalo
***@buffalo.edu<mailto:***@buffalo.edu>