5 Replies Latest reply on Aug 6, 2018 6:03 PM by Maynard with Xenemm

    EBS Cloud DR


      EBS 12.1.3




      Hi ALL,


      I am doing setup of DATAGUARD for our EBS 12.1.3 on-premise (PROD)  to Oracle Cloud (DR).

      Oracle Cloud is very strict in allowing ports from public connection.

      What port do I open (allow) from dataguard to be able to transport log files or archive log files  from local  to  Cloud DR?

      Does it use ftp port (22) or listener port only (1521)?


      Please help....



      Kind regards,

        • 1. Re: EBS Cloud DR
          Maynard with Xenemm

          It will use the listener port.

          • 2. Re: EBS Cloud DR

            Thanks X,


            But I am confused how a port 1521 is able to ftp large archive logs of sizes 1Gb?


            Is there a hidden process of file transfer inside the port?



            Kind regards,

            • 3. Re: EBS Cloud DR
              Maynard with Xenemm

              So when you configure the DR site, you have to tell the primary database the 2nd archive log destination. If you look at that parameter, you can see that it's connecting to the standby database service


              show parameter log_archive_dest_2



              NAME                                 TYPE                           VALUE

              ------------------------------------ ------------------------------ ------------------------------

              log_archive_dest_2                   string                         service="PROD_S", ASYNC NOAFFI

                                                                                  RM delay=0 optional compressio

                                                                                  n=disable max_failure=0 max_co

                                                                                  nnections=1 reopen=300 db_uniq

                                                                                  ue_name="prod_s" net_timeout=3

                                                                                  0, valid_for=(online_logfile,a



              So what that does, is tell the primary database to write a copy of the archivelog to the database service PROD_S, which happens to be a separate database on a different server. Any connections from the primary database will hit the listener and send the connection to the database service you're trying to connect to. The database (PROD_S) knows what to do with the data that's being sent to it and writes it out to a local archivelog file. While the 1Gb of data is being sent over the network, this is considered "in transit" and won't be applied until the archivelog is fully transferred. You have to remember that sqlnet still runs on top of TCP and a byte is still a byte. It's just up to the program receiving the data to decide how to handle it.

              • 4. Re: EBS Cloud DR

                Thanks Xen,



                Is it possible that I have one-way traffic only?

                Meaning my primary db on-premise, can only upload or connect to cloud DR server,

                but the cloud server can not connect to prod due to security issues.

                This way, I only need DR on cloud, and not need to switch back to local on-premise.



                Kind regards,

                • 5. Re: EBS Cloud DR
                  Maynard with Xenemm

                  Well, you can technically do that. I think you have to setup dataguard to maximum performance. I believe what will happen in that case,is that the archivelogs will be sent to the standby system and applied, but the standby database will not be able to respond back to the primary that it successfully applied the log which will leave the dataguard configuration in an "Error" state. You might also have to start the log apply process manually on the standby server.


                  Some other things to consider is that because of the error state, the primary database will not be able mark those archivelogs as applied on the standby and will never be marked for expiration. You'll need to configure RMAN to disregard applying them to standby so they can be obsoleted and deleted, otherwise they will continue to grow and eventually use up all of the disk space and cause the database to freeze while waiting for space to be added.


                  I don't know how locked in to your current DR on cloud system is, but if you're willing to talk and switch to another provider, send me a private message.