WMDIS:11640 - Fixed acknowledgments for PR oracle-livelabs#46

data-guard/active-data-guard-23ai/awr-snapshots/awr-snapshots.md

@@ -79,4 +79,4 @@ Well done!
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/configure-dg/configure-dg.md

@@ -92,13 +92,18 @@ You should have two Cloud Shell tabs connected to the primary and secondary host
 
   ![Steps executed to create and enable the Data Guard configuration](images/create-configuration.png)
 
-  The command `show configuration` should report success. If it's not the case, try using `show configuration verbose` instead, to force a refresh of the status cache.
+  The command `show configuration` should report success. 
 
   ```
   <copy>
   show configuration;
   </copy>
   ```
+  If you see the following warning:
+  ```
+  Warning: ORA-16854: apply lag could not be determined
+  ```
+  Try using `show configuration verbose` instead, to force a refresh of the status cache.
 
   ![Show configuration shows a healthy status](images/show-configuration.png)
 
@@ -110,4 +115,4 @@ You have successfully created the Oracle Data Guard configuration. In the next l
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/create-services/create-services.md

@@ -2,17 +2,17 @@
 
 ## Introduction
 
-Once the Data Guard configuration is in place, it is important to connect to the databases using highly-available connection strings. The connection strings, besides having multiple addresses, require connections to specific application services (for example, the OLTP read-write service for the HR application). The read-write services should only be available on the primary database. If this is not the case, the application will run into problems when connecting to a database that is not available for write operations.  Also, when having a highly-available connection string, it's possible to keep the same connection string across role changes (e.g. after a failover or a switchover), without reconfiguring the application connectivity.
+Once the Data Guard configuration is in place, it is important to connect to the databases using highly-available connection strings. The connection strings, besides having multiple addresses, require connections to specific application services (for example, the OLTP read-write service for the HR application). The read-write services should only be available on the primary database. If this is not the case, the application will have issues when connecting to a database that is not available for write operations.  Also, when having a highly-available connection string, it's possible to keep the same connection string across role changes (e.g. after a failover or a switchover), without reconfiguring the application connectivity.
 
 The services that run only on databases with specific roles are called role-based services.
 
 **Never configure your applications to connect to the default services!** Always use a role-based application service with high availability properties.
 
 **Don't use any PDB saved states!** Saving a PDB's state will automatically open the PDB and the primary role services on the standby database when the PDB is opened there, which can lead to unwanted situations (e.g., the read/write application pointing to the standby database). Always discard the PDB states when configuring Data Guard.
 
-Oracle recommends that you use Oracle Clusterware for Real Application Clusters databases, or Oracle Restart for single instance databases when you need to configure role-based services. The Oracle Data Guard broker is aware of Oracle Clusterware, and delegates the stop and start of the instances to it. Also, Oracle Clusterware optimally manages the role-based services.
+Oracle recommends that you use Oracle Clusterware or Oracle Restart for single instance databases when you need to configure role-based services. For Oracle Real Application Clusters, Oracle Clusterware is a requirement. The Oracle Data Guard broker is aware of Oracle Clusterware, and delegates the stop and start of the instances to it. Also, Oracle Clusterware optimally manages the role-based services.
 
-However, when Oracle Clusterware is not available (like on single-instance deployments on OCI Base Database Services), one has to manage role-based services differently. Typically, we use the `DBMS_SERVICES` package along with startup triggers to stop and start the correct services depending on the database role.
+However, when Oracle Clusterware is not available (like on the database servers created for this lab), one has to manage role-based services differently. Typically, we use the `DBMS_SERVICES` package along with startup triggers to stop and start the correct services depending on the database role.
 
 In this lab, we will create the services for the primary, physical standby, and snapshot standby roles, along with the trigger that stops and starts them. We will then test the connection to the primary service.
 
@@ -134,4 +134,4 @@ You have successfully created, started, and connected to the application role-ba
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/introduction/introduction.md

@@ -45,4 +45,4 @@ The following is intended to outline our general product direction. It is intend
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn, Kamryn Vinson
-- **Last Updated By/Date** -  Ludovico Caldara, May 2024
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/prepare-db/prepare-db.md

@@ -64,21 +64,21 @@ Make sure you are using the `oracle` user.
   * Standby redo logs (SRLs)
   * DB_UNIQUE_NAME
 
-  Because some of these changes might require a restart of the instance, we specified the `restart` keyword to confirm we agree to do that, if required.
+  Because some of these changes require a restart of the instance, we specified the `restart` keyword to confirm we agree to do that, if required.
 
   For more information, [refer to the documentation](https://docs.oracle.com/en/database/oracle/oracle-database/23/dgbkr/oracle-data-guard-broker-commands.html#GUID-46F6267D-E3CF-4544-AC47-A22D9704BAF2).
 
 
 ## Task 2: Clean-up the standby database system
 
 1. On host `adghol1`, get the DB_UNIQUE_NAME of the standby database. On OCI BaseDB, the environment variable `$ORACLE_UNQNAME` is set to the correct value:
-
+  
   ```
   <copy>echo $ORACLE_UNQNAME</copy>
   ```
-
+  
   Note its value down as you will require it many times during this workshop.
-
+  
   **From now on, we'll refer to its value as ADGHOL1_UNIQUE_NAME.**
 
 2. Connect as SYSDBA and shutdown the current database (make sure you are on host `adghol1`):
@@ -280,4 +280,4 @@ You have successfully duplicated and configured the standby database for Data Gu
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/prepare-host/prepare-host.md

@@ -42,13 +42,13 @@ Estimated Lab Time: 15 Minutes
 
 7. Find your ssh private key which has been created earlier to connect to the host where the primary database is located.
 
-  a. If you have used Reserve Workshop on Livelabs option(Green Button), you should have used anyone of the method for generating SSH key pairs using [How to Generate SSH Keys](https://oracle-livelabs.github.io/common/labs/generate-ssh-key/?lab=generate-ssh-keys) .
+  a. If you have used Reserve Workshop on Livelabs option (Green Button), you should have used any of the method for generating SSH key pairs using [How to Generate SSH Keys](https://oracle-livelabs.github.io/common/labs/generate-ssh-key/?lab=generate-ssh-keys) .
 
   Now, you should have the **Public** and **Private** key pair. You must have provided the Public Key while reserving the lab and you need the repsective Private key to connect the DB Server.
 
-  b. If you have used Run on Your Tenancy option (Brown Button), you must use the downloaded public and private keys ( While creating the DB Systems) for connecting to the DB servers.
+  b. If you have used Run on Your Tenancy option (Brown Button), you must use the downloaded public and private keys (While creating the DB Systems) for connecting to the DB servers.
 
-  In all the labs we use Cloud shell to connect to the DB server. You can also connect to the DB servers in anyone of your preferred way such as Terminal in Mac, Powershell in Windows, Putty etc.  Refer the above mentioned link [How to Connect to Servers](https://oracle-livelabs.github.io/common/labs/generate-ssh-key/?lab=generate-ssh-keys) for detailed instructions. Once you are connected to the DB server, **rest of the instructions will remain same**.
+  In all the labs we use Cloud shell to connect to the DB server. You can also connect to the DB servers in any of your preferred way such as Terminal in Mac, Powershell in Windows, Putty etc.  Refer the above mentioned link [How to Connect to Servers](https://oracle-livelabs.github.io/common/labs/generate-ssh-key/?lab=generate-ssh-keys) for detailed instructions. Once you are connected to the DB server, **rest of the instructions will remain same**.
 
 7. Using the **Upload** facility, upload the private key in the **Cloud Shell** environment.
 
@@ -64,7 +64,7 @@ Estimated Lab Time: 15 Minutes
     ````
     <copy>ssh -i cloudshellkey opc@IP_ADDRESS</copy>
     ````
-    Replace `cloudshellkey` with the name of your private key file, and `IP_ADDRESS` with the real public IP address.
+    Replace again `cloudshellkey` with the name of your private key file, and `IP_ADDRESS` with the real public IP address.
 
   You should be connected to the primary database host.
 
@@ -117,7 +117,7 @@ Estimated Lab Time: 15 Minutes
 
   ![Content of listener.ora](images/listener-ora.png)
 
-  The static service registration is required for the duplicate, and also because there is no Oracle Clusterware: the Data Guard has to restart the remote instance with a SQL*Net connection when switching over.
+  The static service registration is required for the duplicate, and also because there is no Oracle Clusterware: Data Guard has to restart the remote instance with a SQL*Net connection when switching over.
 
   By default, without Oracle Clusterware, Data Guard expects a static service named `{DB_UNIQUE_NAME}_DGMGRL.{DOMAIN_NAME}`. It is possible to override this name using the Data Guard property `StaticConnectIdentifier` (we will see that over the next labs).
 
@@ -174,26 +174,26 @@ You have now successfully created a database connection to the primary and the s
 
 1. Download the helper scripts using git:
 
-  ````
-  <copy>
-  git clone -b main -n --filter=tree:0 --depth=1 https://github.com/oracle-livelabs/database-maa.git
-  cd database-maa
-  git sparse-checkout set --no-cone data-guard/active-data-guard-23ai/prepare-host/scripts
-  git checkout
-  </copy>
-  ````
-
+    ````
+    <copy>
+    git clone -b main -n --filter=tree:0 --depth=1 https://github.com/oracle-livelabs/database-maa.git
+    cd database-maa
+    git sparse-checkout set --no-cone data-guard/active-data-guard-23ai/prepare-host/scripts
+    git checkout
+    </copy>
+    ````
+     
 1. Execute the preparation script. This will:
   * Set up a function for the execution of the last version of SQLcl
   * Create the static service registration entry in listener.ora
   * Create the application TNS entries in tnsnames.ora
-
+   
   ```
   <copy>
   sh ~/database-maa/data-guard/active-data-guard-23ai/prepare-host/scripts/prepare.sh
   </copy>
   ```
-
+  
 1. Verify the content of `listener.ora` and `tnsnames.ora`
 
   ```
@@ -203,14 +203,14 @@ You have now successfully created a database connection to the primary and the s
   </copy>
   ```
 
-## Task 5: copy the TDE wallet and password file
+## Task 5: copy the Transparent Data Encryption (TDE) wallet and password file
 
-Oracle Data Guard requires the same TDE master keys in the primary and standby database wallets. The quickest way to achieve that is to copy the entire wallet from the primary to the standby database.
+Oracle Data Guard requires the same Transparent Data Encryption (TDE) master keys in the primary and standby database wallets. The quickest way to achieve that is to copy the entire wallet from the primary to the standby database.
 
 Similarly, the default Data Guard authentication mechanism is to use the password file. The password files must match to ensure that there are no authentication problems.
 
 1. On the primary host (adghol0), copy the keys in a location accessible from the user opc:
-
+  
   ```
   <copy>
   cd /opt/oracle/dcs/commonstore/wallets/$ORACLE_UNQNAME/tde
@@ -219,18 +219,18 @@ Similarly, the default Data Guard authentication mechanism is to use the passwor
   chmod 644 /tmp/orapwadghol
   </copy>
   ```
-
+  
 1. Temporarily go back to the Cloud Shell environment by exiting the shell twice:
-
+  
   ```
   exit
   exit
   ```
-
+  
 1. Copy the wallet and password file from one node to the other, then delete them.
-
+  
   In the following command, replace IP_ADDRESS0 and IP_ADDRESS1 with the public IP addresses of the two hosts you noted down earlier.
-
+  
   ```
   <copy>
   scp -i cloudshellkey opc@IP_ADDRESS0:/tmp/wallet.tar /tmp
@@ -241,11 +241,11 @@ Similarly, the default Data Guard authentication mechanism is to use the passwor
   rm /tmp/orapwadghol
   </copy>
   ```
-
+  
   ![Steps executed to copy the wallet on the second host](images/wallet-copy-1.png)
-
+  
 1. Connect back to the first host and remove the wallet and password file from the temporary location:
-
+  
   ```
   <copy>
   ssh -i cloudshellkey opc@IP_ADDRESS0
@@ -256,7 +256,7 @@ Similarly, the default Data Guard authentication mechanism is to use the passwor
   ```
 
 1. On the standby host (adghol1), copy the files to the correct locations and permissions (as `oracle`), then remove the temporary files as `opc`:
-
+  
   ```
   <copy>
   cd /opt/oracle/dcs/commonstore/wallets/$ORACLE_UNQNAME/tde
@@ -278,4 +278,4 @@ You have successfully prepared the two hosts with everything required to start c
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/real-time-query-dml/real-time-query-dml.md

@@ -6,7 +6,7 @@ You have a copy of your production data on the standby database, so why not use
 A standby database can be open read only while it applies changes coming from the primary database. This feature is called **Real-Time Query**, and it's part of the Active Data Guard option.
 Real-Time Query can offload read-only workloads, such as reports or read-only application modules. If the transport is synchronous, the reading sessions can wait for the received redo to be applied, providing **consistent reads** of all the transactions committed on the primary database.
 
-Additionally, the standby database can be configured to automatically redirect write requests to the primary database, in an ACID-compliant way, with the changes visible only in the the privacy of the transaction started on the standby database.
+Additionally, the standby database can be configured to automatically redirect write requests to the primary database, in an ACID-compliant way, with the changes visible only in the privacy of the transaction started on the standby database.
 This functionality broadens the use cases for the physical standby, including running read-write workloads directly on the standby database. The feature, called **DML Redirection**, also supports DDLs and PL/SQL calls (although with some documented limitations).
 
 Estimated Lab Time: 15 Minutes
@@ -172,4 +172,4 @@ exit
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn;
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/snapshot-standby/snapshot-standby.md

@@ -27,7 +27,7 @@ To try this lab, you must have successfully completed the following labs:
 
 ## Task 1: Convert the physical standby to a snapshot standby
 
-In a window, connect with **dgmgrl** and convert the standby database to a snapshot standby. Don't forget to replace ADGHOL1_UNIQUE_NAME with the actual db_unique_name of the standby database.
+Connect with **dgmgrl** and convert the standby database to a snapshot standby. Don't forget to replace ADGHOL1_UNIQUE_NAME with the actual db_unique_name of the standby database.
 
   ```
   <copy>
@@ -114,4 +114,4 @@ The conversion to physical standby closes the standby database, flashes it back
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/switchover/switchover.md

@@ -90,6 +90,6 @@ You have successfully tested a switchover operation.
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024
 
 

data-guard/active-data-guard-23ai/tac/tac.md

@@ -133,4 +133,4 @@ switchover to ADGHOL0_UNIQUE_NAME
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024

data-guard/active-data-guard-23ai/verify-dg/verify-dg.md

@@ -227,7 +227,7 @@ Oracle Data Guard exposes many fixed views that help observing and monitoring th
    select source_db_unique_name, name, value, time_computed, datum_time from v$dataguard_stats;
    </copy>
    ```
-  The column `VALUE` contains a value different from `+00 00:00:00` for the transport or apply lag if there is a lag (in this case, ecerything is OK).
+  The column `VALUE` contains a value different from `+00 00:00:00` for the transport or apply lag if there is a lag (in this case, everything is OK).
 
    `DATUM_TIME` is extremely important to detect if the standby database is actively receiving data from the primary database. If it does, `DATUM_TIME` will be no more than 1 second older than the current date. Otherwise, you will see `DATUM_TIME` matching the timestamp of the last information received from the primary.
 
@@ -330,4 +330,4 @@ You have successfully verified and altered the Oracle Data Guard configuration.
 
 - **Author** - Ludovico Caldara, Product Manager Data Guard, Active Data Guard and Flashback Technologies
 - **Contributors** - Robert Pastijn
-- **Last Updated By/Date** -  Ludovico Caldara, December 2023
+- **Last Updated By/Date** -  Ludovico Caldara, June 2024