diff --git a/gds/gds-introduction/gds-configuration/gds-service-configuration.md b/gds/gds-introduction/gds-configuration/gds-service-configuration.md
index bfc902263..c44ff1f0e 100644
--- a/gds/gds-introduction/gds-configuration/gds-service-configuration.md
+++ b/gds/gds-introduction/gds-configuration/gds-service-configuration.md
@@ -1,243 +1,402 @@
# Oracle GDS Configuration
-Once databases are ready to configure with GDS as per previous lab "Database updates for enabling GDS", now its time to configure Oracle GDS for Global services using GDSCTL.
+## Introduction
+Now that the databases have been prepared in the previous lab "Database Updates for Enabling GDS," it's time to configure Oracle GDS to enable Global Services using GDSCTL.
-*Estimated Time*: 30 minutes
+Estimated Time: 30 Minutes
-### Objectives
+**Objectives**
In this lab, you will:
-* Use GDSCTL to configure DBs and GSMs for creating Global services to use by Application.
-* Test database connection(s) using global service(s) to verify the GSM configuration.
+* Use GDSCTL to configure databases and GSMs and create Global Services for application use.
+* Test database connections using Global Services to verify the GDS configuration.
-### Prerequisites
+**Prerequisites**
-This lab assumes you have:
-* A Free Tier, Paid or LiveLabs Oracle Cloud account
-* You have completed:
- * Lab: Validate workshop environment
+Before starting this lab, ensure that you have:
+* A Free Tier, Paid, or LiveLabs Oracle Cloud account.
+* Successfully completed the following prerequisite labs::
+ * Lab: Validate Workshop Environment
* Lab: GDS Installation
- * Lab: Database updates to enable GDS
-
-##
-## Task 1: Check the podman container status and connect to gsm1 container
-
-1. Run the below command on terminal window that is logged in as **oracle** user.
-
-```
-
-sudo podman ps -a
-
-```
-
-
-
-2. From a terminal connect to **GSM1**.
-
-```
-
-sudo podman exec -i -t gsm1 /bin/bash
-# View the list of hosts and its ip address used in GDS configuration:
-cat /etc/hosts
-
-```
-
-
-
-## Task 2: Configure GDS with Databases, create global service and validation
-
-1. Run the steps as below to configure the GDS for this live lab env:
-
-```
-
-gdsctl
-set gsm -gsm gsm1
-# Check connectivity to primary catalog
-connect gsmcatuser/Oracle_23ai@catalog.example.com:1521/CAT1PDB;
-
-# Check connectivity to primary Data DB
-connect gsmuser/Oracle_23ai@primary.example.com:1521/ORCLPDB1;
-
-# Check connectivity to standBy Data DB
-connect gsmuser/Oracle_23ai@standby.example.com:1521/ORCLPDB1;
-
-# Re-connect to primary catalog since all gdsctl steps must be run using catalog database
-connect gsmcatuser/Oracle_23ai@catalog.example.com:1521/CAT1PDB;
-
-configure -driver oci
-configure -show
-
-# Create gdscatalog
-create gdscatalog -database "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -user gsmcatuser/Oracle_23ai -region region1 -configname gds01 -autovncr off
-
-# Add gsm1
-add gsm -gsm gsm1 -catalog "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -region region1 -pwd Oracle_23ai
-
-configure -save_config
-start gsm
-
-# For catalog
-add invitednode 10.0.20.102
-# For primary
-add invitednode 10.0.20.103
-# For standBy
-add invitednode 10.0.20.104
-
-# Verify the list of datbase hosts used in this GDS configuration
-config vncr
-#verify that above three ip addresses are listed in the result.
-config gsm
-# You may have to exit & return to gdsctl before running the next command
-exit
-gdsctl
-status gsm
-validate
-# expected output "Total errors: 0. Total warnings:4"
-config
-
-# 23ai onwards, use add database instead of add brokerconfig for the Primary Database
-add database -connect 10.0.20.103:1521/PORCLCDB -region region1 -gdspool dbpoolora -pwd Oracle_23ai -savename
-
-# 23ai onwards, use add database instead of modify database for the StandBy Database to add in brokerconfig
-add database -connect 10.0.20.104:1521/SORCLCDB -region region1 -gdspool dbpoolora -pwd Oracle_23ai -savename
-
-# Add Read-Write Service for the Primary Database
-add service -gdspool dbpoolora -service gds01_rw_srvc_1 -preferred_all -role primary -pdbname ORCLPDB1
-# start Read-Write Service
-start service -service gds01_rw_srvc_1
-
-# Add Read-only Service for the Standby Database
-add service -gdspool dbpoolora -service gds01_ro_srvc_1 -preferred_all -role physical_standby -pdbname ORCLPDB1
-# Start Read-Only Service
-start service -service gds01_ro_srvc_1
-
-```
-
-2. Verify the GDS configuration from GDSCTL
-
-```
-
-status gsm
-
-```
-
-
-
-```
-
-databases
-
-```
-
-
-
-```
-
-status service
-# or
-services
-
-```
-
-
-
-```
-
-validate
-
-```
-
-
-
-```
-
-config
-
-```
-
-
-
-The gdsctl command list can be viewed from gdsctl as below:
-
-```
-
-help
-
-```
-
-For more details about a specific command, use the format as "gdsctl commandName -help".
-
-
-## Task 3: Verify Database connections using GDS services
-
-1. Connect READ-WRITE global service using gsm1
-
-```nohighlighting
-
-sudo podman exec -i -t gsm1 /bin/bash
-# Connect to the global service using sqlplus. Global service connections can be used by the application.
-sqlplus gsmuser/Oracle_23ai@gsm1.example.com:1522/gds01_rw_srvc_1.dbpoolora.gds01;
-# To exit from gsm1 container and return to opc@oraclegdshost
-exit
-exit
-
-```
-
-2. Connect READ-ONLY global service using gsm1
-
-```nohighlighting
-
-sudo podman exec -i -t gsm1 /bin/bash
-# Connect to the global service using sqlplus. Global service connections can be used by the application.
-sqlplus gsmuser/Oracle_23ai@gsm1.example.com:1522/gds01_ro_srvc_1.dbpoolora.gds01;
-# To exit from gsm1 container and return to opc@oraclegdshost
-exit
-exit
-
-```
-
-3. Connect a local service on the catalog DB using gsm1
-
-```nohighlighting
-
-sudo podman exec -i -t gsm1 /bin/bash
-# Connect to the catalog's local service. Similarly, from any of the podman container gsm services using gsm(s) host can be connected.
-sqlplus gsmcatuser/Oracle_23ai@gsm1.example.com:1522/GDS\$CATALOG.gds01;
-exit
-exit
-
-```
-
-Note: Similarly, gsm services can be connected from any of the podman containers e.g. from appclient podman container.
-
-## Task 4: Add gsm2 to GDS configuration (Optional)
-
-If you have already installed GDS on gsm2 container (as described in the Task 5 of Lab "GDS Install"), you can add gsm2 to this GDS configuration.
-
-```nohighlighting
-
-# Connect to the gsm2 podman container:
-sudo podman exec -i -t gsm2 /bin/bash
-gdsctl
-set gsm -gsm gsm2
-add gsm -gsm gsm2 -catalog "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -region region1 -pwd Oracle_23ai
-configure -save_config
-start gsm
-# To see GDS configuration with both gsm1 and gsm2, check it as below:
-config gsm
-config
-exit
-
-```
-
-
-
-This completes GDS configuration tasks and its verification by database connection(s) created using Global service(s).
+ * Lab: Database Updates to Enable GDS
+
+## Task 1: Verify Podman Container Status & Connect to gsm1
+
+1. Check the status of Podman containers (Ensure all required containers are running):
+
+ ```nohighlighting
+
+ sudo podman ps -a
+
+ ```
+
+ 
+
+2. Access the gsm1 container from the terminal:
+
+ ```nohighlighting
+
+ sudo podman exec -i -t gsm1 /bin/bash
+
+ ```
+
+3. Verify /etc/hosts file:
+ ```nohighlighting
+
+ cat /etc/hosts
+
+ ```
+ 
+
+## Task 2: Configure GDS with Databases, Create Global Services, and Validate
+
+**Step 1: Configure GDS for the LiveLab Environment**
+
+1. Launch GDSCTL and set GSM to gsm1:
+ ```nohighlighting
+
+ gdsctl
+ set gsm -gsm gsm1
+
+ ```
+
+2. Verify connectivity to the databases:
+ - GDS Catalog:
+ ```nohighlighting
+
+ connect gsmcatuser/Oracle_23ai@catalog.example.com:1521/CAT1PDB;
+
+ ```
+
+ - Primary Database:
+ ```nohighlighting
+
+ connect gsmuser/Oracle_23ai@primary.example.com:1521/ORCLPDB1;
+
+ ```
+
+ - Standby Database:
+ ```nohighlighting
+
+ connect gsmuser/Oracle_23ai@standby.example.com:1521/ORCLPDB1;
+
+ ```
+
+3. Reconnect to the catalog database (as all GDSCTL steps must be executed from the catalog):
+ ```nohighlighting
+
+ connect gsmcatuser/Oracle_23ai@catalog.example.com:1521/CAT1PDB;
+
+ ```
+
+4. Configure the GDS Driver and Display Configuration:
+ ```nohighlighting
+
+ configure -driver oci
+ configure -show
+
+ ```
+
+
+**Step 2: Create the GDS Catalog and Add GSM Instances**
+
+1. Create the GDS catalog:
+ ```nohighlighting
+
+ create gdscatalog -database "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -user gsmcatuser/Oracle_23ai -region region1 -configname gds01 -autovncr off
+
+ ```
+
+2. Add gsm1 to the GDS configuration:
+ ```nohighlighting
+
+ add gsm -gsm gsm1 -catalog "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -region region1 -pwd Oracle_23ai
+
+ ```
+
+3. Save and start the GSM configuration:
+ ```nohighlighting
+
+ configure -save_config
+ start gsm
+
+ ```
+
+**Step 3: Add Database Hosts to the GDS Configuration**
+1. For each database get the ip address and add those to the GDS configuration:
+
+ ```nohighlighting
+
+ # For the Catalog Database:
+ add invitednode 10.0.20.102
+
+ # For the Primary Database:
+ add invitednode 10.0.20.103
+
+ # For the Standby Database:
+ add invitednode 10.0.20.104
+
+ ```
+
+2. Verify the list of database hosts used in GDS:
+ ```nohighlighting
+
+ config vncr
+
+ ```
+Ensure that the three IP addresses listed above appear in the output.
+
+3. Verify the GSM configuration:
+ ```nohighlighting
+
+ config gsm
+
+ ```
+
+4. Exit and restart GDSCTL:
+ ```nohighlighting
+
+ exit
+ gdsctl
+
+ ```
+
+5. Validate GSM status:
+ ```nohighlighting
+
+ status gsm
+ validate
+
+ ```
+Expected output:
+"Total errors: 0. Total warnings: 4"
+6. Display the current configuration:
+ ```nohighlighting
+
+ config
+
+ ```
+
+**Step 4: Register Databases with GDS**
+
+**Note** that 23ai onwards, add database replaces add brokerconfig.
+
+1. Add the Primary Database:
+ ```nohighlighting
+
+ add database -connect 10.0.20.103:1521/PORCLCDB -region region1 -gdspool dbpoolora -pwd Oracle_23ai -savename
+
+ ```
+
+2. Add the Standby Database:
+ ```nohighlighting
+
+ add database -connect 10.0.20.104:1521/SORCLCDB -region region1 -gdspool dbpoolora -pwd Oracle_23ai -savename
+
+ ```
+
+**Step 5: Create and Start Global Services**
+
+1. Create a Read-Write Service for the Primary Database:
+ ```nohighlighting
+
+ add service -gdspool dbpoolora -service gds01_rw_srvc_1 -preferred_all -role primary -pdbname ORCLPDB1
+
+ ```
+2. Start the Read-Write Service:
+ ```nohighlighting
+
+ start service -service gds01_rw_srvc_1
+
+ ```
+3. Create a Read-Only Service for the Standby Database:
+ ```nohighlighting
+
+ add service -gdspool dbpoolora -service gds01_ro_srvc_1 -preferred_all -role physical_standby -pdbname ORCLPDB1
+
+ ```
+4. Start the Read-Only Service:
+ ```nohighlighting
+
+ start service -service gds01_ro_srvc_1
+
+ ```
+
+**Step 6: Verify the GDS Configuration**
+
+1. Check GSM status:
+ ```nohighlighting
+
+ status gsm
+
+ ```
+ 
+
+
+
+2. Check databases status:
+ ```nohighlighting
+
+ databases
+
+ ```
+ 
+
+3. Check services status:
+ ```nohighlighting
+
+ services
+
+ ```
+ 
+
+4. Use validate command to validate GDS configuration:
+ ```nohighlighting
+
+ validate
+
+ ```
+ 
+
+
+5. Check overall configuration
+ ```nohighlighting
+
+ config
+
+ ```
+ 
+
+6. Use the “gdsctl” command to display help
+ ```nohighlighting
+
+ help
+
+ ```
+
+ Use “gdsctl -help” to obtain detailed help on GDSCTL commands
+
+
+## Task 3: Verify Database Connections Using GDS Services
+
+**Step 1: Connect to the Read-Write Global Service Using gsm1**
+
+1. Access the gsm1 container:
+ ```nohighlighting
+
+ sudo podman exec -it gsm1 /bin/bash
+
+ ```
+2. Connect to the Read-Write Global Service using sqlplus (Global service connections can be used by the application):
+ ```nohighlighting
+
+ sqlplus gsmuser/Oracle_23ai@gsm1.example.com:1522/gds01_rw_srvc_1.dbpoolora.gds01;
+
+ ```
+3. Exit the gsm1 container:
+ ```nohighlighting
+
+ exit
+
+ ```
+
+
+**Step 2: Connect to the Read-Only Global Service Using gsm1**
+
+1. Access the gsm1 container:
+ ```nohighlighting
+
+ sudo podman exec -it gsm1 /bin/bash
+
+ ```
+2. Connect to the Read-Only Global Service using sqlplus (Global service connections can be used by the application):
+ ```nohighlighting
+
+ sqlplus gsmuser/Oracle_23ai@gsm1.example.com:1522/gds01_ro_srvc_1.dbpoolora.gds01;
+
+ ```
+3. Exit the gsm1 container:
+ ```nohighlighting
+
+ exit
+
+ ```
+
+**Step 3: Connect to a Local Service on the Catalog Database Using gsm1**
+
+1. Access the gsm1 container:
+ ```nohighlighting
+
+ sudo podman exec -it gsm1 /bin/bash
+
+ ```
+2. Connect to the catalog's local service (GSM services can also be accessed from other Podman containers, such as appclient):
+ ```nohighlighting
+
+ sqlplus gsmcatuser/Oracle_23ai@gsm1.example.com:1522/GDS$CATALOG.gds01;
+
+ ```
+3. Exit the gsm1 container:
+ ```nohighlighting
+
+ exit
+
+ ```
+Note: GSM services can be accessed from any Podman container, such as the appclient container, for testing and application integration.
+
+
+## Task 4: Add gsm2 to the GDS Configuration (Optional)
+
+If you have already installed GDS on gsm2 (as described in Task 5 of the "GDS Install" Lab), you can now add gsm2 to the GDS configuration.
+
+1. Access the gsm2 Podman container:
+ ```nohighlighting
+
+ sudo podman exec -it gsm2 /bin/bash
+
+ ```
+2. Launch GDSCTL and set GSM to gsm2:
+ ```nohighlighting
+
+ gdsctl
+ set gsm -gsm gsm2
+
+ ```
+3. Add gsm2 to the GDS configuration:
+ ```nohighlighting
+
+ add gsm -gsm gsm2 -catalog "(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=catalog.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CAT1PDB)))" -region region1 -pwd Oracle_23ai
+
+ ```
+4. Save the configuration and start gsm2:
+ ```nohighlighting
+
+ configure -save_config
+ start gsm
+
+ ```
+5. Verify that both gsm1 and gsm2 are now part of the GDS configuration:
+ ```nohighlighting
+
+ config gsm
+ config
+
+ ```
+6. Exit the gsm2 container:
+ ```nohighlighting
+
+ exit
+
+ ```
+ 
+
+This completes GDS configuration and validation tasks.
You may now **proceed to the next lab**.
+
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
\ No newline at end of file
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
\ No newline at end of file
diff --git a/gds/gds-introduction/gds-dbs-configuration/gds-dbs-configuration.md b/gds/gds-introduction/gds-dbs-configuration/gds-dbs-configuration.md
index a5e2ac848..012b57917 100644
--- a/gds/gds-introduction/gds-dbs-configuration/gds-dbs-configuration.md
+++ b/gds/gds-introduction/gds-dbs-configuration/gds-dbs-configuration.md
@@ -1,93 +1,158 @@
-# Database updates for enabling GDS
+# Database Updates for Enabling GDS
-Database(s) needs to be GDS enabled before configuring GDS using GDSCTL. In this lab, we'll run the shell scripts which has the SQL commands for database configurations.
-*Estimated Time*: 15 minutes
+## Introduction
-### Objectives
+Before configuring GDS using GDSCTL, each database must be GDS-enabled. In this lab, we will execute shell scripts containing the necessary SQL commands for database configuration.
-In this lab, you will:
+Estimated Time: 15 Minutes
-* Configure each Database for commands to be run using sysdba.
-* Verify Database are ready, so that we can start GDS configuration using GDSCTL in the next lab.
-### Prerequisites
-This lab assumes you have:
-* A Free Tier, Paid or LiveLabs Oracle Cloud account
-* You have completed:
- * Lab: Validate workshop environment
- * Lab: GDS Installation
+**Objectives**
-##
-## Task 1: Connect to Podman instance of Catalog Primary DB
+In this lab, you will:
-1. Apply Database Configuration for Catalog which will be used in "create gdscatalog.." at the later stage from gsm1 to apply GDS configuration steps.
+* Configure each database by executing the required commands as SYSDBA.
+* Verify that the databases are ready for GDS configuration, which will be performed using GDSCTL in the next lab.
-You will run "configure_catalog.sh" which mainly:
-* Unlocks GSMCATUSER on both CDB and PDB of the catalog database.
-* Enables ARCHIVELOG, FLASHBACK, and FORCE LOGGING if not enabled.
-* Restarts database in READ WRITE mode.
+**Prerequisites**
+
+Before starting this lab, ensure that you have:
+* A Free Tier, Paid, or LiveLabs Oracle Cloud account.
+* Successfully completed the following prerequisite labs:
+ * Lab: Validate Workshop Environment
+ * Lab: GDS Installation
-```
-
-sudo podman exec -it catalog /bin/bash
-# View the contents of "configure_catalog.sh". This file doesn't need any updates for this LiveLab task.
-cat configure_catalog.sh
+## Task 1: Configure the Catalog Database
+Before proceeding with GDS configuration, the GDS Catalog Database must be prepared. The GDS Catalog database can be a standalone or shared database and will contain the GDS catalog (a repository of metadata about the GDS configuration such as regions, database pools, global services, etc.).
-# Run the script
-./configure_catalog.sh
-exit
-
-```
+This task ensures that the database is properly configured before running the CREATE GDSCATALOG command, which will be executed later from gsm1.
-## Task 2: Connect to Podman instance of Primary Database for Application
-1. Prepare Primary Database for the application. This primary database will be used in "add database" at later stage from gsm1 to apply GDS configuration steps.
+**What This Configuration Does**
-You will run "configure_primary.sh" which mainly:
-* Unlocks GSMUSER on both CDB and PDB of the primary database.
-* Unlocks GSMROOTUSER on CDB only of the primary database.
+You will run the script configure_catalog.sh. This script performs the following tasks on the GDS Catalog database:
+* Unlocks GSMCATUSER on both CDB and PDB of the catalog database.
* Enables ARCHIVELOG, FLASHBACK, and FORCE LOGGING if not enabled.
* Restarts database in READ WRITE mode.
-```
-
-sudo podman exec -it primary /bin/bash
-# View the contents of "configure_primary.sh". This file doesn't need updates for this LiveLab task.
-cat configure_primary.sh
-# Run the script
-./configure_primary.sh
-exit
-
-```
-
-## Task 3: Connection to Podman instance of StandBy Database for Application Data
-
-1. Though no updates needed at this time for the standby database, you can still verify its PDB is in READ ONLY mode.
-
-```nohighlighting
-
-sudo podman exec -it standby /bin/bash
-# Login as sysDBA and Verify that PDBs are in READ ONLY OPEN MODE
-sqlplus / as sysdba;
-show pdbs;
-select open_mode from v$database;
-# To exit from standby container and return to opc@oraclegdshost
-exit
-exit
-
-```
-
-
-
-This completes database tasks.
-
-Note: Review the contents of each of the database scripts to get familiar with the necessary steps needed prior to GDSCTL configuration steps.
-
-Since You have installed GSM already, now you can perform the next Lab **GDS Configuration using GDSCTL**
+**Steps to Configure the Catalog Database**
+
+1. Access the Catalog Database container:
+ ```nohighlighting
+
+ sudo podman exec -it catalog /bin/bash
+
+ ```
+2. View the contents of configure_catalog.sh (No modifications are required for this LiveLab task):
+ ```nohighlighting
+
+ cat configure_catalog.sh
+
+ ```
+3. Execute the script to apply the necessary configurations:
+ ```nohighlighting
+
+ ./configure_catalog.sh
+
+ ```
+4. Exit the container session:
+ ```nohighlighting
+
+ exit
+
+ ```
+
+## Task 2: Configure the Primary Database for the Application
+Before proceeding with GDS configuration, the Primary Database must be prepared. This task ensures that the database is properly configured before the ADD DATABASE command is executed later from gsm1.
+
+
+**What This Configuration Does**
+
+You will run the script configure_primary.sh, which performs the following tasks:
+
+* Unlocks GSMUSER in both the CDB and PDB of the primary database.
+* Unlocks GSMROOTUSER in the CDB only of the primary database.
+* Enables ARCHIVELOG, FLASHBACK, and FORCE LOGGING (if not already enabled).
+* Restarts the database in READ WRITE mode.
+
+
+**Steps to Configure the Primary Database**
+
+1. Access the Primary Database container:
+ ```nohighlighting
+
+ sudo podman exec -it primary /bin/bash
+
+ ```
+2. View the contents of configure_primary.sh (No modifications are required for this LiveLab task):
+ ```nohighlighting
+
+ cat configure_primary.sh
+
+ ```
+3. Execute the script to apply the necessary configurations:
+ ```nohighlighting
+
+ ./configure_primary.sh
+
+ ```
+4. Exit the container session:
+ ```nohighlighting
+
+ exit
+
+ ```
+
+## Task 3: Verify the Standby Database for Application Data
+
+Although no updates are required for the standby database at this stage, you can verify that its PDB is in READ ONLY mode.
+
+**Steps to Verify the Standby Database**
+
+1. Access the Standby Database container:
+ ```nohighlighting
+
+ sudo podman exec -it standby /bin/bash
+
+ ```
+2. Log in as SYSDBA and verify the PDB open mode:
+ ```nohighlighting
+
+ sqlplus / as sysdba
+
+ ```
+3. Check the status of all PDBs:
+ ```nohighlighting
+
+ show pdbs
+
+ ```
+4. Confirm that the database is in READ ONLY mode:
+ ```nohighlighting
+
+ select open_mode from v$database;
+
+ ```
+5. Exit the SQL session and container:
+ ```nohighlighting
+
+ exit
+
+ ```
+ 
+
+## Conclusion
+
+Database Configuration Completed.
+
+This concludes the database configuration tasks.
+
+**Note**: It is recommended to review the contents of each database script to understand the key configuration elements required before proceeding with GDSCTL setup. Now that GSM is installed, you are ready to move on to the next lab: Oracle GDS Configuration
You may now **proceed to the next lab**
+
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
\ No newline at end of file
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
\ No newline at end of file
diff --git a/gds/gds-introduction/gds-global-service-test/gds-global-service-test.md b/gds/gds-introduction/gds-global-service-test/gds-global-service-test.md
index 41a445db8..b7d8d90cc 100644
--- a/gds/gds-introduction/gds-global-service-test/gds-global-service-test.md
+++ b/gds/gds-introduction/gds-global-service-test/gds-global-service-test.md
@@ -1,102 +1,160 @@
-# Prepare a sample Schema and Test Global Service
+# Prepare a Sample Schema and Test Global Service
-Once GDS's Global service(s) are configured, those can be used in database connect strings. These connect strings can be used from client-sides e.g., using SQL, PL/SQL, Java, python etc.
+## Introduction
-*Estimated Time*: 15 minutes
+Now that GDS Global Services are configured, they can be used in database connection strings. These connection strings can be utilized from various client applications, including SQL, PL/SQL, Java, Python, and more.
-### Objectives
+Estimated Lab Time: 15 Minutes
+
+**Objectives**
In this lab, you will:
-* Use Global services connection.
-* Prepare a sample schema.
-* Run a sample shell script to from the appclient container to insert records.
-* Prepare a jdbc connect string using global service to be used with Java based application.
+* Use a Global Services connection for database access.
+* Create a sample schema for testing.
+* Execute a sample shell script from the appclient container to insert records.
+* Prepare a JDBC connection string using a Global Service for Java-based applications.
-### Prerequisites
+**Prerequisites**
-This lab assumes you have:
-* A Free Tier, Paid or LiveLabs Oracle Cloud account
-* You have completed:
- * Lab: Validate workshop environment
+Before starting this lab, ensure that you have:
+* A Free Tier, Paid, or LiveLabs Oracle Cloud account.
+* Successfully completed the following prerequisite labs:
+ * Lab: Validate Workshop Environment
* Lab: GDS Installation
- * Lab: Database updates to enable GDS
- * Lab: GDS Configuration using GDSCTL
-
-##
-## Task 1: Create a schema from "appclient" podman container
-
-1. Run the below command on the new terminal window that is logged in as **oracle** user.
-
-```
-
-sudo podman exec -i -t appclient /bin/bash
-su - oracle
-
-```
-
-2. Using a Global service, prepare app_schema
-
-```
-
-# View the contents of a shell script which creates a schema using a database connection with global service:
-cat appclient_schema_prep.sh
-
-# Run the script to prepare app_schema as below:
-./appclient_schema_prep.sh
-
-```
-
-3. Verify the output of prepare app_schema
-
-
-
-## Task 2: Insert records in app_schema.emp table from "appclient" podman container
-
-We are Using a Global service connection in "insert_records.sh".
-
-```
-
-# View the contents of a shell script which continuously inserts records in app_schema.emp table using a database connection with global service
-cat insert_records.sh
-
-# Run the script
-./insert_records.sh
-
-```
-
-5. Verify the output of insert records in app_schema
-
-
+ * Lab: Database Updates to Enable GDS
+ * Lab: GDS Configuration Using GDSCTL
+
+## Task 1: Create a Schema from the appclient Podman Container
+
+**Step 1: Access the appclient Container**
+
+1. Open a new terminal window and ensure you are logged in as the oracle user.
+2. Run the following command to access the appclient container:
+ ```nohighlighting
+
+ sudo podman exec -i -t appclient /bin/bash
+
+ ```
+
+3. Switch to the oracle user inside the container:
+ ```nohighlighting
+
+ su - oracle
+
+ ```
+
+**Step 2: Prepare app_schema Using a Global Service**
+
+1. View the contents of the schema preparation script:
+ ```nohighlighting
+
+ cat appclient_schema_prep.sh
+
+ ```
+2. Execute the script to create app_schema:
+ ```nohighlighting
+
+ ./appclient_schema_prep.sh
+
+ ```
+
+**Step 3: Verify Schema Creation Output**
+
+- Review the output to confirm that app_schema has been successfully created.
+
+ 
+
+## Task 2: Insert Records into app_schema.emp Table from the appclient Podman Container
+
+**Step 1: View the Script Contents**
+
+We are using a Global Service connection in the script insert\_records.sh, which continuously inserts records into the app\_schema.emp table.
+
+1. To review the script contents, run:
+
+ ```nohighlighting
+
+ cat insert_records.sh
+
+ ```
+
+**Step 2: Run the Script**
+
+1. Execute the script to start inserting records:
+
+ ```nohighlighting
+
+ ./insert_records.sh
+
+ ```
+
+**Step 3: Verify the Inserted Records**
+
+* Review the script output to confirm that records are successfully inserted into the app_schema.emp table.
+* The "HOST_NAME" value in the result should indicate the primary database in the Data Guard configuration, which is currently set to primary.
+* The Global Service automatically connects to the current primary database.
+ 
This result shows the "HOST_NAME" value as primary database in Data-Guard configuration which is currently set to "primary". Global service connects with the current primary database.
-## Task 3. Test Global service connection string with both gsms (for load-balance / disaster recovery)
-
-1. Connect app_schema using Global service connection string with both gsms for load-balance / disaster recovery like below:
-
-```
-
-sqlplus app_schema/Oracle_23ai@'(DESCRIPTION=(FAILOVER=ON)(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(ADDRESS=(HOST=gsm1.example.com)(PORT=1522)(PROTOCOL=tcp))(ADDRESS=(HOST=gsm2.example.com)(PORT=1522)(PROTOCOL=tcp)) )(CONNECT_DATA=(SERVICE_NAME=gds01_rw_srvc_1.dbpoolora.gds01)))';
-
-```
-
-2. How to connect Application using JDBC URL of Global service? (optional)
-
-For example using the global service "gds01\_rw\_srvc\_1.dbpoolora\.gds01":
-
-```nohighlighting
-jdbc:oracle:thin:@((DESCRIPTION=(FAILOVER=ON)(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(ADDRESS=(HOST=gsm1.example.com)(PORT=1522)(PROTOCOL=tcp))(ADDRESS=(HOST=gsm2.example.com)(PORT=1522)(PROTOCOL=tcp)) )(CONNECT_DATA=(SERVICE_NAME=gds01_rw_srvc_1.dbpoolora.gds01)))
-```
-
-Note: Such Global Service's JDBC URL can be used from application to connect Oracle database via Global Service.
-
-This completes Global service usage and its verification by insert records in a sample application schema.
+## Task 3. Test Global Service Connection String with Both GSMs (For Load Balancing & Disaster Recovery)
+**Step 1: Connect to app_schema Using the Global Service Connection String**
+
+1. To enable load balancing and disaster recovery, connect to app_schema using the Global Service connection string that includes both gsm1 and gsm2:
+
+ ```nohighlighting
+
+ sqlplus app_schema/Oracle_23ai@'
+ (DESCRIPTION=
+ (FAILOVER=ON)
+ (CONNECT_TIMEOUT=5)
+ (TRANSPORT_CONNECT_TIMEOUT=3)
+ (RETRY_COUNT=3)
+ (ADDRESS_LIST=
+ (ADDRESS=(HOST=gsm1.example.com)(PORT=1522)(PROTOCOL=tcp))
+ (ADDRESS=(HOST=gsm2.example.com)(PORT=1522)(PROTOCOL=tcp))
+ )
+ (CONNECT_DATA=(SERVICE_NAME=gds01_rw_srvc_1.dbpoolora.gds01))
+ )';
+
+ ```
+
+**Step 2: (Optional) Connect an Application Using a JDBC URL for Global Service**
+1. For **Java-based applications**, you can use the following **JDBC connection URL** to connect via the Global Service gds01\_rw_srvc\_1.dbpoolora\.gds01:
+
+ ```nohighlighting
+
+ jdbc:oracle:thin:@(
+ (DESCRIPTION=
+ (FAILOVER=ON)
+ (CONNECT_TIMEOUT=5)
+ (TRANSPORT_CONNECT_TIMEOUT=3)
+ (RETRY_COUNT=3)
+ (ADDRESS_LIST=
+ (ADDRESS=(HOST=gsm1.example.com)(PORT=1522)(PROTOCOL=tcp))
+ (ADDRESS=(HOST=gsm2.example.com)(PORT=1522)(PROTOCOL=tcp))
+ )
+ (CONNECT_DATA=(SERVICE_NAME=gds01_rw_srvc_1.dbpoolora.gds01))
+ )
+ )
+
+ ```
+
+**Note:** This Global Service JDBC URL allows applications to connect to the Oracle database via the Global Service, ensuring high availability and failover support.
+
+## Conclusion
+
+Successfully tested the Global Service connection with both GSMs for load balancing and disaster recovery.
+
+Verified database access using a Global Service connection from SQL.
+
+This completes the Global Service usage and verification. You may now proceed to the next lab.
You may now **proceed to the next lab**.
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
diff --git a/gds/gds-introduction/gds-install/gds-install.md b/gds/gds-introduction/gds-install/gds-install.md
index 2dd383be4..fb3bca055 100644
--- a/gds/gds-introduction/gds-install/gds-install.md
+++ b/gds/gds-introduction/gds-install/gds-install.md
@@ -1,173 +1,231 @@
# Oracle GDS Installation
+## Introduction
-## GDS Installation Overview
+To manage the GDS environment, the Global Data Services Control Utility (GDSCTL) is used for setup, configuration, and administration.
-A Global Data Services (GDS) installation can be done either before or after preparing the databases. We use terms GSM (Global Services Manager) to manage via setup involves the installation of Global Service Manager software and the creation of a GDS catalog in a new or existing database. Global services are configured on target database pools which consist of primary and standby or replica databases. Global Data Services Control Utility (GDSCTL) manages the GDS setup.
+Installing Oracle Global Data Services (GDS) involves two key steps:
+1. Installing the Global Service Manager (GSM) software.
+2. Creating a GDS catalog in either a new or an existing database.
-*Estimated Time*: 20 minutes
+Once installed, global services are configured within a target database pool, which typically consists of a primary database and one or more standby or replica databases.
-### Objectives
+Estimated Time: 15 Minutes
-In this lab, you will:
+**Objectives**
+
+In this section, you will:
* Prepare the GDS container(s) before install.
-* Run GDS install.
-* Verify GDS install.
+* Execute the GDS installation process.
+* Verify the successful installation of GDS.
-### Prerequisites
+**Prerequisites**
-This lab assumes you have:
+Before starting this lab, ensure that you have:
* A Free Tier, Paid or LiveLabs Oracle Cloud account
-* You have completed:
- * Lab: Validate workshop environment
-
-*Additional Pre-requisites already taken care in this Live lab env* but those may be needed for non-Live-lab GDS env as below:
-
-### 1. GDS uses three Ports and those must be opened
-
-```nohighlighting
- a. The listener port (default 1522)
- b. The local ons port (default 6123)
- c. The remote ons port (default 6234)
-```
-
-### 2. Make sure that same Time Zone is used in all machines/containers for GDS and/or Databases
-
-```nohighlighting
- e.g., If UTC is used for Databases, but machines for GSM(s) is using GMT. In such cases, set timezone to UTC on GSM machine(s) as well.
- This Live-Lab already set to use UTC, so no update needed.
-```
-
-### 3. All Databases with same version and same character-set to be used. No update needed for this Live-Lab
-
-
-## Task 1: Check for containers in your VM
-
-1. Run the below command on terminal window that is logged in as **oracle** user.
-
-```
-
-sudo podman ps -a
-
-```
-
-
-
-2. From a terminal connect to **gsm1** container as below:
-
-```
-
-sudo podman exec -i -t gsm1 /bin/bash
-
-```
-
-## Task 2: GSM Pre-install steps
-
-```
-
-# ORACLE_HOME is already set to /u01/app/oracle/product/23ai/gsmhome_1. It's also referred as *gsmhome* for GDS purposes.
-unzip /opt/oracle/install/LINUX.X64_237000_gsm.zip -d $ORACLE_HOME
-# For GDS install use its response file: 23ai_gsm_install.rsp without any updates.
-cd $ORACLE_HOME
-cat /opt/oracle/install/23ai_gsm_install.rsp
-
-```
-
-
-
-
-## Task 3: Install GSM software
-
-```
-
-# If you are not in [oracle@gsm1 gsmhome_1]$
-sudo podman exec -it gsm1 /bin/bash
-cd $ORACLE_HOME
-# run install command
-./runInstaller -silent -responseFile /opt/oracle/install/23ai_gsm_install.rsp
-
-```
-
-Wait (for approx 20 seconds) till installation completes.
-
-
+* Completed the following prerequisite lab:
+ * Lab: Validate Workshop Environment
+
+**Additional Pre-requisites**
+
+These prerequisites are already configured in this LiveLabs environment but may be required for non-LiveLabs GDS environments.
+
+1. GDS requires the following ports to be open
+
+ - Listener port: Default 1522
+ - Local ONS port: Default 6123
+ - Remote ONS port: Default 6234
+
+2. Ensure consistent time zone settings across all machines/containers used for GDS and databases.
+
+ - Example: If databases use UTC, but the Global Service Managers (GSMs) run on machines set to GMT, update the GSM machines to UTC to maintain synchronization. Note that the LiveLabs environment is already set to UTC, so no changes are needed.
+
+3. All databases must have the same version and character set.
+
+ - LiveLabs Configuration: The databases in this LiveLabs environment already meet this requirement, so no further action is required.
+
+## Task 1: Verify Running Containers in Your VM
+1. Open a terminal window and ensure you are logged in as the **oracle** user.
+2. Execute the following command to list all containers:
+
+ ```nohighlighting
+
+ sudo podman ps -a
+
+ ```
+
+ 
+
+3. From the terminal connect to the **gsm1** container:
+
+ ```nohighlighting
+
+ sudo podman exec -i -t gsm1 /bin/bash
+
+ ```
+ This command opens an interactive bash session inside the gsm1 container.
+
+## Task 2: GSM Pre-Installation Steps
+
+1. Verify ORACLE_HOME
+
+ - The ORACLE\_HOME environment variable is already set to /u01/app/oracle/product/23ai/gsmhome_1
+ ```nohighlighting
+
+ echo $ORACLE_HOME
+
+ ```
+ - For GDS-related operations, this directory is referred to as gsmhome.
+
+2. Extract the GSM software
+
+ - Run the following command to extract the GSM software zip file into the Oracle Home directory:
+ ```nohighlighting
+
+ unzip /opt/oracle/install/LINUX.X64_237000_gsm.zip -d $ORACLE_HOME
+
+ ```
+
+3. Use the Default GDS Response File for Installation
+ - The GDS installation utilizes the pre-configured response file 23ai\_gsm\_install.rsp without any modifications.
+ - To review the response file, run:
+ ```nohighlighting
+
+ cd $ORACLE_HOME
+ cat /opt/oracle/install/23ai_gsm_install.rsp
+
+ ```
+ 
+
+
+## Task 3: Install GSM Software
+
+1. Access the gsm1 container (if not already inside):
+ ```nohighlighting
+
+ sudo podman exec -it gsm1 /bin/bash
+
+ ```
+2. Navigate to the Oracle Home Directory (if not already inside):
+ ```nohighlighting
+
+ cd $ORACLE_HOME
+
+ ```
+3. Run the GSM Installation Command:
+ ```nohighlighting
+
+ ./runInstaller -silent -responseFile /opt/oracle/install/23ai_gsm_install.rsp
+
+ ```
+
+4. Wait for the installation to complete (approximately 20 seconds)
+
+ 
+
+
+## Task 4: Post-Installation Steps
+
+1. Run orainstRoot.sh as the root user:
+ - Switch to the root user:
+ ```nohighlighting
+
+ sudo su -
+ # now you are in [root@gsm1 ~]#
+
+ ```
+ - Execute the following script:
+ ```nohighlighting
+
+ /u01/app/oracle/oraInventory/orainstRoot.sh
+
+ ```
+ - Verify the script output
+ 
+
+2. Modify /etc/oratab as the root user:
+
+ - Append the following line to /etc/oratab:
+ ```nohighlighting
+
+ echo 'gsm:/u01/app/oracle/product/23ai/gsmhome_1:N' >> /etc/oratab
+
+ ```
+ - Verify that the line has been added by running:
+ ```nohighlighting
+
+ cat /etc/oratab
+
+ ```
+ - Exit the root session:
+ ```nohighlighting
+
+ exit
+
+ ```
+3. Verify the output
+ 
+
+## Task 5: Verify GDSCTL Installation
+
+1. Access the gsm1 container (if not already inside):
+
+ ```nohighlighting
+
+ sudo podman exec -it gsm1 /bin/bash
+
+ ```
+
+2. Launch GDSCTL to confirm the installation:
+ ```nohighlighting
+
+ gdsctl
+
+ ```
+
+3. Verify the GDSCTL prompt appears, then exit:
+ ```nohighlighting
+
+ exit
+
+ ```
+
+4. The output would like as below:
+
+ 
+
+
+## Task 6: (Optional) Install GDS on gsm2 for High Availability
+For high availability, you can install GDS on "gsm2" container. To do so:
+
+1. Access the gsm2 container:
+ ```nohighlighting
+
+ sudo podman exec -it gsm2 /bin/bash
+
+ ```
+
+2. Follow the same installation steps as gsm1:
+
+ - Repeat Task 2, Task 3, and Task 4 inside the gsm2 container.
+
+
+**Note:** Why Install GDS on Multiple GSM Containers?
+
+If gsm1 becomes unavailable due to patching, maintenance, or an unplanned event, gsm2 will automatically take over as the primary GSM, ensuring continuous service availability. Multiple Global Service Managers (GSMs) enhance redundancy and fault tolerance. Once gsm2 is installed, it can be included in the database connection string for seamless failover.
+
+## Conclusion
+
+This completes the GDS installation tasks.
+
+The next lab focuses on database updates required for enabling GDS.
+You may now **proceed to the next lab**
-## Task 4: Post Install steps
-
-1. Run orainstRoot.sh as a root user
-```
-
-sudo su -
-# now you are in [root@gsm1 ~]#
-/u01/app/oracle/oraInventory/orainstRoot.sh
-
-```
-
-2. Verify the output as below:
-
-
-
-
-3. As a root user, edit /etc/oratab to add one line as below:
-
-```
-
-# To log-in as a root user:
-sudo su -
-# now you are in [root@gsm1 ~]#
-echo 'gsm:/u01/app/oracle/product/23ai/gsmhome_1:N' >> /etc/oratab
-# cat /etc/oratab to verify a new line has been added
-cat /etc/oratab
-exit
-
-```
-
-4. Verify the output as below:
-
-
-
-5. Run GDSCTL to confirm the successful installation.
-
-```
-
-#If you are not in [oracle@gsm1 gsmhome_1]$ run below:
-sudo podman exec -it gsm1 /bin/bash
-
-# To see GDSCTL prompt
-gdsctl
-# after verify exit for now.
-exit
-
-```
-
-6. Verify the output as below:
-
-
-
-
-## Task 5: From gsm2 container install GDS (optional)
-
-Similarly, you can install GDS on "gsm2" container for high availability.
-For that you can switch container to gsm2 as below:
-
-```
-
-sudo podman exec -it gsm2 /bin/bash
-
-```
-
-Follow the tasks 2, 3 and 4 as performed for gsm1.
-
-Note: When gsm1 goes down for some reasons e.g. patching or for disaster recovery etc. scenarios, gsm2 will become master gsm to serve the application without any disruptions. Therefore, we can use more than one Global Service Managers (GSMs).
-When gsm2 is installed, it can also be added to connect string which will test after database and GSM configurations are done.
-
-This completes GDS installation tasks. **Database updates for enabling GDS** is the next lab.
-You may now **proceed to the next lab**
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
diff --git a/gds/gds-introduction/gds-switchover-failover/gds-switchover-failover.md b/gds/gds-introduction/gds-switchover-failover/gds-switchover-failover.md
index 34da9c730..5e415791f 100644
--- a/gds/gds-introduction/gds-switchover-failover/gds-switchover-failover.md
+++ b/gds/gds-introduction/gds-switchover-failover/gds-switchover-failover.md
@@ -1,172 +1,289 @@
-# Switchover and Failover tests while using Global services
+# Switchover and Failover Tests Using Global Services
-Once global service(s) created along with Data guard configuration as per previous lab, now it’s time to run Switchover and Failover tests. Application continuity is expected with zero data loss during Switchover and Failover tests for connections using Global services.
+## Introduction
+Now that Global Services and Data Guard are configured (as per the previous lab), it’s time to test Switchover and Failover scenarios.
+During these tests, application continuity should be maintained with zero data loss for connections using Global Services.
-*Estimated Time*: 20 minutes
+Estimated Time: 30 Minutes
-### Objectives
+**Objectives**
In this lab, you will:
-* Use DGMGRL to run and verify Switchover and Failover tests.
-* Verify "insert record" script runs continuously with zero data loss during Switchover and Failover tests.
+* Use DGMGRL to perform and verify Switchover and Failover tests.
+* Ensure the "insert record" script runs continuously without data loss during Switchover and Failover operations.
-### Prerequisites
+**Prerequisites**
-This lab assumes you have:
+Before starting this lab, ensure that you have:
-* A Free Tier, Paid or LiveLabs Oracle Cloud account
-* You have completed:
- * Lab: Validate workshop environment
+* A Free Tier, Paid, or LiveLabs Oracle Cloud account.
+* Successfully completed the following prerequisite labs:
+ * Lab: Validate Workshop Environment
* Lab: GDS Installation
- * Lab: Database updates to enable GDS
- * Lab: GDS Configuration using GDSCTL
- * Lab: Prepare a sample Schema and Test Global Service
-
-##
-## Task 1: Prior to perform Switchover from primary to standby, make sure insert_records.sh is running from appclient container
-
-1. From the appclient container, start the test (if not running already, in a different terminal window):
-
-```
-
-# From another terminal window
-sudo podman exec -i -t appclient /bin/bash
-su - oracle
-# Run the script
-./insert_records.sh
-
-```
-
-## Task 2: Perform Switchover from primary to standby cdb (sorclcdb)
-
-1. From another terminal window, connect to the primary container to perform Switchover to standby
-
-```
-
-sudo podman exec -it primary /bin/bash
-dgmgrl
-connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
-show configuration
-switchover to sorclcdb
-
-```
-
-2. From appclient container, verify that when Switchover from primary to standby gets started, connection errors occurs:
-
-
-
-Wait for Switchover completion. It may complete soon but sometimes it may take up to 3 minutes in this liveLab environment. You can monitor from appclient terminal that records started inserting again using new primary which is sorclpdb. After Failover completion, note that HOST_NAME is "standby" as expected.
-
-3. From appclient container, verify Switchover from primary to standby is completed and you see records getting inserted again using new primary cdb (sorclpdb) belongs to standby container:
-
-
-
-Look at the value of ID prior to start Switchover and after Switchover completion. ID doesn't skip!. This confirms that Switchover happened with zero data loss.
-
-4. Verify Switchover to standbydb (sorclcdb) is completed.
-
-
-
-5. Similarly, you can verify from standby container (optional):
-
-```
-
-sudo podman exec -it standby /bin/bash
-dgmgrl
-connect sys/Oracle_23ai@standby.example.com:1521/sorclcdb
-show configuration
-
-```
-
+ * Lab: Database Updates to Enable GDS
+ * Lab: GDS Configuration Using GDSCTL
+ * Lab: Prepare a Sample Schema and Test Global Service
+
+## Task 1: Ensure insert_records.sh is Running Before Switchover
+
+Before performing a Switchover from Primary to Standby, ensure that the insert\_records.sh script is running on the appclient container. This verifies that data insertion continues seamlessly during the transition.
+
+**Steps to Start insert_records.sh on appclient**
+
+1. Open another terminal window and access the appclient container:
+ ```nohighlighting
+
+ sudo podman exec -i -t appclient /bin/bash
+
+ ```
+2. Switch to the oracle user inside the container:
+ ```nohighlighting
+
+ su - oracle
+
+ ```
+3. Run the script to start continuous record insertion:
+ ```nohighlighting
+
+ ./insert_records.sh
+
+ ```
+
+## Task 2: Perform Switchover from Primary to Standby (sorclcdb)
+
+**Step 1: Initiate the Switchover from Primary to Standby**
+
+1. Open a new terminal and connect to the primary container:
+ ```nohighlighting
+
+ sudo podman exec -it primary /bin/bash
+
+ ```
+2. Launch Data Guard Manager (DGMGRL) and connect to the primary database:
+ ```nohighlighting
+
+ dgmgrl
+ connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
+
+ ```
+3. Check the current Data Guard configuration:
+ ```nohighlighting
+
+ show configuration
+
+ ```
+4. Perform the Switchover to Standby (sorclcdb):
+ ```nohighlighting
+
+ switchover to sorclcdb
+
+ ```
+
+**Step 2: Monitor Connection Errors During Switchover (From appclient)**
+
+1. Switch to the appclient container (where insert_records.sh is running):
+ - As the Switchover process begins, connection errors may briefly appear.
+ - The process typically completes within a few minutes but may take up to 3 minutes in this LiveLab environment.
+2. Wait for the Switchover to complete and observe that records begin inserting again, now using the new primary (sorclpdb).
+3. After the Switchover completes, verify that HOST_NAME now reflects the new primary database.
+ 
+
+**Step 3: Verify the Switchover Completion**
+
+1. Confirm that records are being inserted again using the new primary database (sorclpdb).
+2. Check the value of ID before and after the Switchover:
+ - The ID sequence should not skip, confirming a successful Switchover with zero data loss.
+
+ 
+
+
+**Step 4: Validate Switchover to Standby (sorclcdb)**
+
+1. Ensure that the Switchover to sorclcdb (previously Standby) is complete.
+ 
+
+**Step 5: (Optional) Verify from the Standby Container**
+
+1. Access the standby container:
+ ```nohighlighting
+
+ sudo podman exec -it standby /bin/bash
+
+ ```
+2. Launch DGMGRL and connect to the standby database:
+ ```nohighlighting
+
+ dgmgrl
+ connect sys/Oracle_23ai@standby.example.com:1521/sorclcdb
+
+ ```
+3. Check the Data Guard configuration:
+ ```nohighlighting
+
+ show configuration
+
+ ```
-
-## Task 3: Perform Failover to current standby database which is primary cdb (porclcdb)
-
-1. Keep the insert script running from the appclient container or it can be started again:
-
-```
-
-sudo podman exec -i -t appclient /bin/bash
-#run the script
-./insert_records.sh
-
-```
-
-2. From the another terminal window, connect to primary container (if not already) and perform Failover to current standby CDB (porclcdb):
-
-
-```
-
-sudo podman exec -it primary /bin/bash
-dgmgrl
-connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
-show configuration
-failover to PORCLCDB
-
-```
-
-3. From the appclient container, verify that "insert\_records.sh" is running during Failover to porclpdb. Prior to Failover completion, note that HOST_NAME is "standby"
-
-
+**Task Completion**
+
+Successfully performed and validated a Switchover from Primary to Standby.
+
+Ensured continuous data insertion without data loss.
+
+Verified the new primary database (sorclpdb) is active.
+
+Proceed to the next task to test Failover scenarios.
+
+
+## Task 3: Perform Failover to the Current Standby Database (porclcdb)
+
+**Step 1: Ensure insert\_records.sh is Running on appclient**
+
+Before initiating the Failover, ensure that the insert\_records.sh script is running.
+
+1. Access the appclient container:
+ ```nohighlighting
+
+ sudo podman exec -it appclient /bin/bash
+
+ ```
+
+2. Start the insert script (if not already running):
+ ```nohighlighting
+
+ ./insert_records.sh
+
+ ```
+
+**Step 2: Initiate Failover to the Current Standby (porclcdb)**
+
+1. Open a new terminal and connect to the primary container:
+ ```nohighlighting
+
+ sudo podman exec -it primary /bin/bash
+
+ ```
+2. Launch Data Guard Manager (DGMGRL) and connect to the primary database:
+ ```nohighlighting
+
+ dgmgrl
+ connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
+
+ ```
+3. Check the current Data Guard configuration:
+ ```nohighlighting
+
+ show configuration
+
+ ```
+4. Perform the Failover to PORCLCDB:
+ ```nohighlighting
+
+ failover to PORCLCDB
+
+ ```
+
+**Step 3: Monitor the insert_records.sh Output from appclient**
+
+- Observe the output from the appclient terminal while Failover is in progress.
+- Before Failover completes, HOST_NAME will be "standby".
-4. Wait for Failover completion. It may complete soon but sometimes it may take up to 3 minutes in this liveLab environment. You can monitor from appclient terminal that records started inserting again using new primary which is sorclpdb. After Failover completion, note that HOST_NAME is "primary" as expected.
-
-
-
-5. After Failover completes, confirm from primary container that porclcdb becomes primary again:
+**Step 4: Wait for Failover Completion**
+
+- The Failover process may complete quickly, but in some cases, it might take up to 3 minutes in this LiveLab environment.
+- Once complete, records will begin inserting again, now using the new primary (sorclpdb).
+- After Failover, verify that HOST_NAME is now "primary"` as expected.
+
+ 
+
+**Step 5: Confirm That porclcdb is the New Primary Database**
+
+1. Access the primary container:
+ ```nohighlighting
+
+ sudo podman exec -it primary /bin/bash
+
+ ```
+2. Launch DGMGRL and reconnect to the database:
+ ```nohighlighting
+
+ dgmgrl
+ connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
+
+ ```
+3. Check the updated Data Guard configuration:
+ ```nohighlighting
+
+ show configuration
+
+ ```
+
-```
-
-sudo podman exec -it primary /bin/bash
-dgmgrl
+Note: Application continues to run on the new primary database.
+
+**Step 6: Reinstate the Standby Database (sorclcdb)**
+
+1. While insert\_records.sh continues running, you may see an error indicating that
+"The standby database must be reinstated."
+2. Start the standby database and verify its state:
+ ```nohighlighting
+
+ sudo podman exec -it standby /bin/bash
+ sqlplus / as sysdba
+ startup
+ show pdbs
+
+ ```
+3. Confirm that OPEN_MODE is now READ ONLY, which indicates that the standby database is in the desired state.
+ 
+
+
+**Step 7: Verify the Final Configuration from the Primary Container**
+
+1. Access the primary container:
+ ```nohighlighting
+
+ sudo podman exec -it primary /bin/bash
+
+ ```
+2. Launch DGMGRL and reconnect to the database:
+ ```nohighlighting
+
+ dgmgrl
+
+ ```
connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
-show configuration
-
-```
-
-
+3. Check the final Data Guard configuration:
+ ```nohighlighting
+
+ show configuration
+
+ ```
+ 
-Application continues to run from primary.
-6. Note that though "insert\_records" application is running while connecting to HOST_NAME "primary" but an error is shown that "The standby database must be reinstated.".
-To reinstate standby, you can start the standby database and verify as below:
+**Task Completion**
-```
-
-sudo podman exec -it standby /bin/bash
-sqlplus / as sysdba
-startup
-show pdbs
-
-```
+Successfully performed and validated a Failover from Primary to Standby.
-
+Ensured continuous data insertion with zero data loss.
-"OPEN\_MODE" is now "READ ONLY" and this step confirms that "standby" database is in the desired state.
+Reinstated the standby database after Failover.
-7. Verify from primary container as below:
+This confirms that the insert_records test runs successfully with zero data loss during Switchover and Failover.
-```
-
-sudo podman exec -it primary /bin/bash
-dgmgrl
-connect sys/Oracle_23ai@primary.example.com:1521/porclcdb
-show configuration
-
-```
+Similarly, any other application using Global Service connections can be verified under Switchover and Failover conditions.
-
+## Conclusion
-This step confirms that "insert\_records" test is running with zero data loss during Switchover or Failover.
-Similarly, any other application using global service connections can be verified with zero data loss during Switchover or Failover.
+This completes the Oracle GDS Introduction LiveLabs.
-This Completes the GDS introduction LiveLabs.
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
\ No newline at end of file
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
\ No newline at end of file
diff --git a/gds/gds-introduction/introduction/images/gds-workshop-topology.png b/gds/gds-introduction/introduction/images/gds-workshop-topology.png
index 24bfb110c..6e4c410ac 100644
Binary files a/gds/gds-introduction/introduction/images/gds-workshop-topology.png and b/gds/gds-introduction/introduction/images/gds-workshop-topology.png differ
diff --git a/gds/gds-introduction/introduction/introduction.md b/gds/gds-introduction/introduction/introduction.md
index ba5271942..7375de65d 100644
--- a/gds/gds-introduction/introduction/introduction.md
+++ b/gds/gds-introduction/introduction/introduction.md
@@ -1,16 +1,16 @@
-# Oracle Global Data Services Overview
+# Introduction to Oracle Global Data Services (GDS)
## About Oracle Database Global Data Services (GDS)
Oracle Database provides a powerful workload management feature called database services. Database services are named representations of one or more database instances. Database services allow you to group database workloads, ensure client requests are routed to the optimal instance that offers a service, and provide high availability by transparently failing client connections over to surviving instances when a planned or unplanned instance outage occurs.
-Oracle Global Data Services (GDS) extends the Oracle Database service model to a set of replicated databases.
+Oracle Global Data Services (GDS) extends the Oracle Database service model to a set of replicated and distributed databases.
A Global Data Services configuration looks like a virtual multi-instance database to database clients. It provides client access through global services, which are functionally similar to the local database services provided by single-instance or Oracle Real Application Clusters (Oracle RAC) databases. Local and global services both provide load balancing, high availability, and resource management. The essential difference between global services and local services is that global services span the instances of multiple databases, whereas local services span the instances of a single database.
-A Global Data Services configuration and its global services are created and managed using the GDS Control Utility (GDSCTL) command-line interface (CLI). The GDSCTL CLI is similar to the SRVCTL CLI that is used to manage an Oracle RAC Database and its services.
+A Global Data Services configuration and its global services are created and managed using the GDS Control Utility (GDSCTL) command-line interface (CLI). The GDSCTL CLI is similar to the SRVCTL CLI that is used to manage an Oracle RAC Database and its services.
-*Estimated Workshop Time:* 2 hours
+**Total Estimated Workshop Time: 2 hours**
**Global Service Manager (GSM)**:
@@ -25,22 +25,23 @@ For database clients, a Global Data Services configuration is presented by a set
**Objectives**
-- This workshop will give you first-hand experience with Global Data Services (GDS) setup, configuration, and usage.
+- This workshop will give you first-hand experience with Global Data Services (GDS) setup, configuration, and basic usage.
This includes:
- GSM software installation and GDS Catalog creation
- Primary and Standby database setup (in an Active Data Guard configuration)
-- Creating global services for RW and RO workloads and application setup
+- Creating global services for RW and RO workloads
+- Application setup
- Testing and validating global services in action using the GDS Control Utility (GDSCTL)
- Switchover and Failover tests using Global services
-Note: This workshop uses Podman containers for simplicity and focus on the workshop objectives.
+**Note:** This workshop uses Podman containers for simplicity.
**Prerequisites**
-- An Oracle Cloud Account - Please view this workshop's LiveLabs landing page to see which environments are supported
-- Basic understanding of an Oracle Database, Oracle Data Guard, Database Services
+- An Oracle Cloud Account - Please view this workshop's LiveLabs landing page to see which environments are supported.
+- Basic understanding of an Oracle Database, Oracle Data Guard, and Database Services.
You may now **proceed to the next lab**
@@ -48,7 +49,8 @@ You may now **proceed to the next lab**
- [Introduction to Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/23/gsmug/intro-global-data-services.html#GUID-415B8BB5-5C8D-4C78-8E76-43DB1648E467)
+
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
diff --git a/gds/gds-introduction/validate-workshop-environment/validate-workshop-environment.md b/gds/gds-introduction/validate-workshop-environment/validate-workshop-environment.md
index be701adc3..c10eeb7d2 100644
--- a/gds/gds-introduction/validate-workshop-environment/validate-workshop-environment.md
+++ b/gds/gds-introduction/validate-workshop-environment/validate-workshop-environment.md
@@ -1,70 +1,85 @@
-# Validate the workshop environment
+# Validate Workshop Environment
## Introduction
-In this lab we will review status of podman containers required to successfully run this workshop.
+In this lab, you will review the status of the Podman containers required to successfully run this workshop.
-*Estimated Lab Time:* 5 Minutes.
+Estimated Time: 5 Minutes
-### Objectives
-- Validate the workshop environment.
+**Objectives**
+- Validate the workshop environment by ensuring all required containers are running.
-## Task 1: Validate that required podman containers are Up and Running
+## Task 1: Verify Required Podman Containers
-1. Open a terminal session to review the Oracle GDS LiveLab's Podman processes by running the command as below:
+This workshop utilizes Podman containers to host:
-```
-
-sudo podman ps -a
-
-```
+ - GSM Servers
+ - GDS Catalog Database Server
+ - Primary and Standby Database Servers
+ - Application Client Host
-
+**Steps to Validate Podman Containers**
-2. We are using Podman containers for this workshop. The following Podman containers should be up and running:
+1. Open a terminal session.
+2. Check the status of all Podman containers by executing:
- - Oracle GSM1 Container
- - Oracle GSM2 Container
- - Oracle Catalog Primary Database container
- - Oracle Application Primary Database container
- - Oracle Application StandBy Database container
- - Appclient Container
-
-3. If any of the podmain container is stopped and not in running state then try to restart it by using below podman commands:
-
- a. stop or start one podman container at a time
```
- sudo podman stop
-
-
- sudo podman start
+ sudo podman ps -a
```
- e.g.,
- ```nohighlighting
- sudo podman stop gsm1
- sudo podman start gsm1
- ```
+ 
- b. For multiple containers, run the following to restart all at once:
+## Task 2: Verify Running Podman Containers
+Ensure that the following Podman containers are actively running:
+ - gsm1 – Global Service Manager (GSM) Container #1
+ - gsm2 – Global Service Manager (GSM) Container #2 (for HA)
+ - catalog – Container hosting the GDS Catalog Database
+ - primary – Container hosting the Primary Database
+ - standby – Container hosting the Standby Database
+ - appclient – Container hosting the Application Client
- ```
-
- sudo podman container stop $(sudo podman container list -qa)
-
-
- sudo podman container start $(sudo podman container list -qa)
-
- ```
+## Task 3. Restarting Podman Containers (If Required)
+ If any Podman container is stopped and not running, restart it using the following commands:
+
+### Restarting a Single Container
+
+ To stop or start individual Podman container, use:
+ ```nohighlighting
+ sudo podman stop
+ sudo podman start
+ ```
+
+### Example:
+ ```nohighlighting
+ sudo podman stop gsm1
+ sudo podman start gsm1
+ ```
+
+### Restarting Multiple Containers at Once
+
+ To stop and start all containers simultaneously, use:
+
+ ```nohighlighting
+ sudo podman container stop $(sudo podman container list -qa)
+ sudo podman container start $(sudo podman container list -qa)
+ ```
+
+## Conclusion
+
+ Workshop validation complete.
+
+ You have successfully validated the workshop environment.
+
+ You can stop/start Podman containers as needed throughout this workshop.
-This completes the validating the workshop environment and stop/start podman containers as and when needed during this workshop.
You may now **proceed to the next lab**
+
## Acknowledgements
-* **Author** - Ajay Joshi, Distributed Database Product Management
-* **Contributors** - Ravi Sharma, Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
-* **Last Updated By/Date** - Ajay Joshi, February 2025
+* **Authors** - Ajay Joshi, Ravi Sharma, Distributed Database Product Management
+* **Contributors** - Vibhor Sharma, Jyoti Verma, Param Saini, Distributed Database Product Management
+* **Last Updated By/Date** - Ajay Joshi, March 2025
diff --git a/gds/gds-introduction/workshops/sandbox/manifest.json b/gds/gds-introduction/workshops/sandbox/manifest.json
index 62c33f2b7..25502c3f9 100644
--- a/gds/gds-introduction/workshops/sandbox/manifest.json
+++ b/gds/gds-introduction/workshops/sandbox/manifest.json
@@ -3,8 +3,8 @@
"help": "livelabs-help-db_us@oracle.com",
"tutorials": [
{
- "title": "Oracle Global Data Services Overview",
- "description": "Oracle Global Data Services Overview",
+ "title": "Introduction to Oracle Global Data Services (GDS)",
+ "description": "Introduction to Oracle Global Data Services (GDS)",
"filename": "../../introduction/introduction.md"
},
{
@@ -13,8 +13,8 @@
"filename": "https://oracle-livelabs.github.io/common/labs/cloud-login/cloud-login-23ai.md"
},
{
- "title": "Lab 1: Validate the workshop environment",
- "description": "Validate the workshop environment",
+ "title": "Lab 1: Validate Workshop Environment",
+ "description": "Validate Workshop Environment",
"filename": "../../validate-workshop-environment/validate-workshop-environment.md"
},
{
@@ -23,8 +23,8 @@
"filename": "../../gds-install/gds-install.md"
},
{
- "title": "Lab 3: Database updates to enable GDS",
- "description": "Database updates to enable GDS",
+ "title": "Lab 3: Database Updates for Enabling GDS",
+ "description": "Database Updates for Enabling GDS",
"filename": "../../gds-dbs-configuration/gds-dbs-configuration.md"
},
{
@@ -33,13 +33,13 @@
"filename": "../../gds-configuration/gds-service-configuration.md"
},
{
- "title": "Lab 5: Prepare a sample Schema and Test Global Service",
- "description": "Prepare a sample Schema and Test Global Service",
+ "title": "Lab 5: Prepare a Sample Schema and Test Global Service",
+ "description": "Prepare a Sample Schema and Test Global Service",
"filename": "../../gds-global-service-test/gds-global-service-test.md"
},
{
- "title": "Lab 6: Switchover and Failover tests while using Global services",
- "description": "Switchover and Failover tests while using Global services",
+ "title": "Lab 6: Switchover and Failover Tests Using Global Services",
+ "description": "Switchover and Failover Tests Using Global Services",
"filename": "../../gds-switchover-failover/gds-switchover-failover.md"
},
{