Oracle DataGuard - Step-by-Step - Create a Physical Standby Database Using OEM

  Рет қаралды 2,200

YouVolve

YouVolve

Күн бұрын

Пікірлер: 12
@Keith-vz4ed
@Keith-vz4ed Жыл бұрын
Very good instruction. Thank you.
@YouVolve
@YouVolve Жыл бұрын
Thanks for your feedback.
@utmizzou
@utmizzou 15 күн бұрын
very good thank you
@YouVolve
@YouVolve 15 күн бұрын
Thank you for your feedback.
@zulalinho007
@zulalinho007 Жыл бұрын
Thanks , it is useful tutorial.
@YouVolve
@YouVolve Жыл бұрын
Glad it was helpful!
@joseluisdelarosa728
@joseluisdelarosa728 10 ай бұрын
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,
@YouVolve
@YouVolve 10 ай бұрын
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.
@joseluisdelarosa728
@joseluisdelarosa728 10 ай бұрын
@@YouVolve Hi. Perfect again ! Thank you very much !!! Pleasure
@joseluisdelarosa728
@joseluisdelarosa728 10 ай бұрын
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!
@YouVolve
@YouVolve 10 ай бұрын
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.
@joseluisdelarosa728
@joseluisdelarosa728 10 ай бұрын
@@YouVolve I really appreciate the clarity and depth of your response; the effort and knowledge you've shared are evident. Best regards
Арыстанның айқасы, Тәуіржанның шайқасы!
25:51
QosLike / ҚосЛайк / Косылайық
Рет қаралды 684 М.
How many people are in the changing room? #devil #lilith #funny #shorts
00:39
create physical standby database step by step oracle 19c || Data guard configuration steps
1:13:51
Oracle 12c Data Guard Create Physical Standby Database
54:14
Ahmed Baraka
Рет қаралды 45 М.
Oracle 19c Data Guard 01 Step By Step Setup
36:57
Database Guy
Рет қаралды 31 М.
Create Database on Oracle Cloud | K21Academy
42:53
K21Academy
Рет қаралды 11 М.
Delta Live Tables A to Z: Best Practices for Modern Data Pipelines
1:27:52
Active Data Guard best practices to optimize DR strategy
38:17