Very insightful video on creating a physical standby database using OEM 13.5. I wanted to share an important consideration for those of us operating in environments with separated roles for oracle and grid users, especially when the listener is configured and running under the grid software, listening on port 1521. In my case, I plan to follow the steps outlined in the video, but with a specific adaptation for my environment. For those in a similar situation, where the main listener is managed by the grid user, it is possible to create an additional listener under the oracle user, using a different port than the main listener to avoid conflicts ? For example, I'm considering setting up a new listener on the primary database running under the oracle user and listening on port 1523. This setup would allow me to maintain separated network service management for different purposes or requirements, and I wonder if this new listener would also be copied automatically to the standby database as part of the creation process through OEM. I'm going to test this configuration on my virtual machines to verify its feasibility and effectiveness. Has anyone tried something similar or has experience with creating additional listeners in segregated oracle and grid environments? Any insights or recommendations based on your experience would be greatly appreciated. Additionally, I'm curious about the best practices following the duplication process concerning the task-specific listeners created for this purpose. Specifically, I'm contemplating whether these listeners, set up under the oracle user for the duplication task, should be removed after the process is complete. This consideration is to ensure that the listener running under the grid user can dynamically register the new standby database without any conflicts or redundancy. Thanks in advance for sharing your knowledge!
Hi Jose, thanks for watching my video and providing your feedback. I really appreciate for your time to watch it so keenly and validating every pros and cons. To answer your question, yes absolutely, you can have a separate listener with a different port for this purpose that runs from the Oracle Home (local listener) and not from the grid home (remote listener). A local listener is not managed by the clusterware. Please note that, as mentioned in the prerequisites, the listener in the standby server should be pre-created. OEM will not copy it from the primary server. Although I have not tested, but you can remove the dedicated listener that you just created for the duplication purposes once the setup is done as long as the primary can reach out to the net service of the standby using another listener. Hope this has answered your question.
I noticed during the walkthrough that the DB_UNIQUE_NAME parameter is being changed as part of the setup process. While this is a crucial step for differentiating between the primary and standby databases, it might be worth mentioning for the sake of clarity and completeness that changing this parameter in a production database typically requires modifying the SPFILE, followed by a database restart to apply the changes. However, in a production environment, such a restart might not always be viable due to the requirement for high availability and minimal downtime. Additionally, it would be interesting to know if the demonstration you're conducting could be performed without altering the DB_UNIQUE_NAME parameter. This could present a more straightforward approach for those looking to test or implement a standby database without impacting their current setup. Thank you again for the educational content, and I look forward to any insights you might have on this matter. Best regards,
Hello Jose, thank for watching my video and providing your feedback. Yes, you can absolutely create the standby without a production DB downtime if the default unique name that the production DB currently has is okay for you. Only thing is you must specify a proper unique name for the standby when you create it. If the mandatory parameters for a data guard environment that require an instance bounce already have the values set, you can go ahead and create the standby without a downtime in your production/primary database. Please let me know if I was able to answer your questions.
Very good instruction. Thank you.
Thanks for your feedback.
Very insightful video on creating a physical standby database using OEM 13.5. I wanted to share an important consideration
for those of us operating in environments with separated roles for oracle and grid users, especially when the
listener is configured and running under the grid software, listening on port 1521.
In my case, I plan to follow the steps outlined in the video, but with a specific adaptation for my environment.
For those in a similar situation, where the main listener is managed by the grid user, it is possible to create
an additional listener under the oracle user, using a different port than the main listener to avoid conflicts ?
For example, I'm considering setting up a new listener on the primary database running under the oracle user and listening on port 1523.
This setup would allow me to maintain separated network service management for different purposes or requirements,
and I wonder if this new listener would also be copied automatically to the standby database as part of the
creation process through OEM. I'm going to test this configuration on my virtual machines to verify its feasibility and effectiveness.
Has anyone tried something similar or has experience with creating additional listeners in segregated oracle
and grid environments? Any insights or recommendations based on your experience would be greatly appreciated.
Additionally, I'm curious about the best practices following the duplication process concerning the task-specific listeners created for this purpose. Specifically, I'm contemplating whether these listeners, set up under the oracle user for the duplication task, should be removed after the process is complete. This consideration is to ensure that the listener running under the grid user can dynamically register the new standby database without any conflicts or redundancy.
Thanks in advance for sharing your knowledge!
Hi Jose, thanks for watching my video and providing your feedback. I really appreciate for your time to watch it so keenly and validating every pros and cons. To answer your question, yes absolutely, you can have a separate listener with a different port for this purpose that runs from the Oracle Home (local listener) and not from the grid home (remote listener). A local listener is not managed by the clusterware. Please note that, as mentioned in the prerequisites, the listener in the standby server should be pre-created. OEM will not copy it from the primary server. Although I have not tested, but you can remove the dedicated listener that you just created for the duplication purposes once the setup is done as long as the primary can reach out to the net service of the standby using another listener. Hope this has answered your question.
@@YouVolve I really appreciate the clarity and depth of your response; the effort and knowledge you've shared are evident. Best regards
I noticed during the walkthrough that the DB_UNIQUE_NAME parameter is being changed as part of the setup process.
While this is a crucial step for differentiating between the primary and standby databases, it might be worth
mentioning for the sake of clarity and completeness that changing this parameter in a production database
typically requires modifying the SPFILE, followed by a database restart to apply the changes.
However, in a production environment, such a restart might not always be viable due to the requirement
for high availability and minimal downtime.
Additionally, it would be interesting to know if the demonstration you're conducting could be performed
without altering the DB_UNIQUE_NAME parameter. This could present a more straightforward approach for
those looking to test or implement a standby database without impacting their current setup.
Thank you again for the educational content, and I look forward to any insights you might have on this matter.
Best regards,
Hello Jose, thank for watching my video and providing your feedback. Yes, you can absolutely create the standby without a production DB downtime if the default unique name that the production DB currently has is okay for you. Only thing is you must specify a proper unique name for the standby when you create it. If the mandatory parameters for a data guard environment that require an instance bounce already have the values set, you can go ahead and create the standby without a downtime in your production/primary database. Please let me know if I was able to answer your questions.
@@YouVolve Hi. Perfect again ! Thank you very much !!! Pleasure
Thanks , it is useful tutorial.
Glad it was helpful!