Wednesday, November 20, 2024

Oracle DataGuard SWITCHOVER Primary to DR using DGMGRL

 Below are all the steps to be followed to SWITCHOVER from Primary to DR database using Oracle 19c DGMGRL broker utility. 

Prepare for the switchover

Before starting the switchover process, make sure that both the primary and standby databases are synchronized and that all required logs have been applied to the standby database. Also, ensure that the broker is configured and running on both the primary and standby sites.

Step 1: Check Archvie Gap

Before starting the switchover activity let's verify the archive gap between primary and standby.

On Primary:

SQL> select thread#, max(sequence#) "Last Primary Seq# Generated" from v$archived_log v, v$database d
where v.resetlogs_change# = d.resetlogs_change#
group by thread# order by 1;

   THREAD# Last Primary Seq# Generated
---------- ---------------------------
         1                          27

On Standby:

SQL> select thread#, max(sequence#) "Last Primary Seq# Generated" from v$archived_log v, v$database d
where v.resetlogs_change# = d.resetlogs_change#
group by thread# order by 1;  2    3

   THREAD# Last Primary Seq# Generated
---------- ---------------------------
         1                          27

Step 2: Connect to the broker

Connect to the broker using the dgmgrl utility on the primary database. For example, you can run the command "dgmgrl /" to connect to the default broker configuration.

[oracle@primary ~]$ dgmgrl sys/pwd
Welcome to DGMGRL, type "help" for information.
Connected to "digital"
Connected as SYSDBA.

Step 3: Verify the configuration

Verify that the broker configuration is correct by running the "show configuration" command. This will display the current configuration settings for the broker.

DGMGRL> show configuration

Configuration - digital

  Protection Mode: MaxPerformance
  Members:
  digital - Primary database
    digidr  - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 51 seconds ago)

In this configuration, we have Primary Database "DIGITAL" and the standby Database is "DIGIDR".

Step 4: Prepare for the switchover

Prepare for the switchover by running the "validate database" command to ensure that both the primary and standby databases are ready for switchover.

Validate Primary Database

DGMGRL> validate database digital;

  Database Role:    Primary database

  Ready for Switchover:  Yes

  Flashback Database Status:
    digital:  Off

  Managed by Clusterware:
    digital:  NO
    Validating static connect identifier for the primary database digital...
    The static connect identifier allows for a connection to database "digital".

Validate Standby Database

DGMGRL> validate database digidr;

  Database Role:     Physical standby database
  Primary Database:  digital

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    digital:  Off
    digidr :  Off

  Managed by Clusterware:
    digital:  NO
    digidr :  NO
    Validating static connect identifier for the primary database digital...
    The static connect identifier allows for a connection to database "digital".

  Current Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (digital)               (digidr)
    1         3                       2                       Insufficient SRLs

  Future Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (digidr)                (digital)
    1         3                       0                       Insufficient SRLs
    Warning: standby redo logs not configured for thread 1 on digital

Step 5: Initiate the switchover

Initiate the switchover by running the "switchover to " command in dgmgrl. This will start the switchover process and automatically failover the primary database to the standby database.

DGMGRL> switchover to digidr;
Performing switchover NOW, please wait...
Operation requires a connection to database "digidr"
Connecting ...
Connected to "digidr"
Connected as SYSDBA.
New primary database "digidr" is opening...
Operation requires start up of instance "digital" on database "digital"
Starting instance "digital"...
Connected to an idle instance.
ORACLE instance started.
Connected to "digital"
Database mounted.
Database opened.
Connected to "digital"
Switchover succeeded, new primary is "digidr"

Step 6: Verify the switchover

After the switchover, verify that the new primary database is running by running the "show database" command in dgmgrl.

Current Primary digidr

DGMGRL> show database digidr

Database - digidr

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    digidr

Database Status:
SUCCESS

Current standby digital

DGMGRL> show database digital

Database - digital

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 0 Byte/s
  Real Time Query:    ON
  Instance(s):
    digital

Database Status:
SUCCESS

Database Warnings

Sometimes you will face the below error, then you have to check the log_archive_dest_1 and log_archive_dest_2 parameter on the standby side and configure it properly.

DGMGRL> show database digital

Database - digital

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      (unknown)
  Apply Lag:          (unknown)
  Average Apply Rate: (unknown)
  Real Time Query:    ON
  Instance(s):
    digital

  Database Warning(s):
    ORA-16854: apply lag could not be determined
    ORA-16856: transport lag could not be determined
    ORA-16858: last communication time from redo source could not be determined

Database Status:
WARNING


DGMGRL> show database digidr;

Database - digidr

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    digidr
      Error: ORA-16736: unable to find the destination entry of member "digital" in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property RedoRoutes found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property LogXptMode found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property DelayMins found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property Binding found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property MaxFailure found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property ReopenSecs found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST
      Warning: ORA-16728: consistency check for property RedoCompression found ORA-16777 error
      Warning: ORA-16777: unable to find the destination entry of a member in V$ARCHIVE_DEST

Database Status:
ERROR

Step 7: Reconfigure the environment

If necessary, reconfigure the environment to point to the new primary database. For example, update connection strings, DNS entries, or load balancer settings to point to the new primary database.

Step 8: Start Recovery

After the switchover start the MRP process using the broker or manually.

Enable with Broker:

DGMGRL> EDIT DATABASE digital SET STATE='APPLY-ON';
Succeeded.

Check MRP status using SQL command, if no row is selected that means MRP is disabled.

SQL> select inst_id, process, status from gv$managed_standby where process='MRP0';

   INST_ID PROCESS   STATUS
---------- --------- ------------
         1 MRP0      APPLYING_LOG

Disable with Broker

DGMGRL> EDIT DATABASE digital SET STATE='APPLY-OFF';

Enable/Disable manually:

SQL> alter database recover managed standby database disconect from session;

SQL> alter database recover managed standby database cancel;

Note

Note that the exact steps for performing a switchover using a broker may vary depending on your specific configuration and requirements. It is important to carefully review the Oracle Data Guard documentation and consult with experienced database administrators before attempting a switchover.

Tuesday, October 1, 2024

Change PostgreSQL DATA DIRECTORY to a New location

 In PostgreSQL, the database files are typically stored in the data directory, which contains the configuration files, database clusters, and other essential files. The exact location of the data directory depends on your PostgreSQL installation and operating system.

Here are common locations for the PostgreSQL data directory:

1. Linux-based systems

  • The data directory is usually located in:
    • /var/lib/postgresql/<version>/main/
    • Example: /var/lib/postgresql/12/main/

You can find the location by checking the PostgreSQL service file or querying the database.

2. Windows

  • On Windows, the default data directory might be:
    • C:\Program Files\PostgreSQL\<version>\data
    • Example: C:\Program Files\PostgreSQL\13\data

3. macOS

  • If PostgreSQL is installed via Homebrew, the data directory is typically:
    • /usr/local/var/postgres

4. Custom Installations

  • If PostgreSQL was compiled from source or installed in a custom location, the data directory will be specified during the initialization of the database cluster using the initdb command. In that case, it would be the path you specified.

Finding the Data Directory in PostgreSQL

You can determine the exact location of the data directory by running the following SQL query in the PostgreSQL environment:

postgers=# SHOW data_directory;

data_directory
/var/lib/postgresql/12/main

To change the location of the PostgreSQL data directory, you need to follow a series of steps carefully. The process involves stopping the PostgreSQL service, moving the data files to the new location, configuring PostgreSQL to use the new directory, and starting the service again.

Here’s a step-by-step guide:

1. Stop the PostgreSQL Service

Before moving any files, stop the PostgreSQL service to avoid any corruption or data loss.

  • On Linux (systemd):

sudo systemctl stop postgresql

  • On Windows: Stop the PostgreSQL service via the Services app (services.msc), or run:

net stop postgresql

2. Copy the Data Directory to the New Location

Next, move the contents of the current data directory to the new location. Be sure to use a command that preserves file permissions and ownership.

  • On Linux:

sudo rsync -av /current/data/directory/ /new/data/directory/

  • On Windows: Use file explorer or the command prompt to move the files:

xcopy "C:\current\data\directory" "D:\new\data\directory" /E /I /H /K /O /X /Y

3. Update PostgreSQL Configuration

Now, you need to update the PostgreSQL configuration to point to the new data directory.

  • For Linux (systemd):

    1. Open the PostgreSQL service configuration file (usually located in /etc/postgresql/<version>/main/postgresql.conf).
    2. Modify the data_directory parameter

data_directory = '/new/data/directory'

For Windows:

  1. Open the PostgreSQL configuration file (postgresql.conf) located in the PostgreSQL installation directory.
  2. Update the data_directory setting to point to the new location.

4. Set the Correct Ownership and Permissions

Ensure that the new data directory has the correct ownership and permissions.

  • On Linux: Change ownership to the PostgreSQL user (usually postgres):

sudo chown -R postgres:postgres /new/data/directory

sudo chmod 700 /new/data/directory

  • On Windows: Ensure that the user running PostgreSQL (usually NETWORK SERVICE or postgres) has full control over the new directory.

5. Start PostgreSQL with the New Data Directory

Start PostgreSQL, and it should now use the new data directory.

  • On Linux (systemd):

sudo systemctl start postgresql

  • On Windows: Start the service from the Services app or via command:

net start postgresql

6. Verify the New Data Directory

After starting PostgreSQL, verify that it’s using the new data directory by running the following command:

postgres=# SHOW data_directory;

data_directory 

  /new/data/directory 

(1 row)

7. Clean Up (Optional)

After confirming that everything works correctly, you can remove the old data directory to free up space:

sudo rm -rf /old/data/directory

Be careful with this step#7 and make sure the new setup is fully functional before
deleting the old files.

For any DBA related questions on below databases, please email me samiappsdba@gmail.com
Oracle, Oracle EBS Apps DBA, PostgreSQL, Microsoft SQL Server, IBM DB2

Thursday, September 5, 2024

Top Oracle Commands & Utilities

1. Oracle Database Commands and Tools:

- SQL*Plus: A command-line tool used for running SQL and PL/SQL commands and scripts against Oracle databases.
- expdp (Export Data Pump): Used to export data and metadata from an Oracle database into a set of dump files.
- impdp (Import Data Pump): Used to import data and metadata from dump files into an Oracle database.
- DBCA (Database Configuration Assistant): DBCA is a utility provided by Oracle to simplify the creation, configuration, and management of Oracle databases.
- DBUA (Database Upgrade Assistant): DBUA is a utility provided by Oracle to automate the process of upgrading an existing Oracle database to a newer version.
- NETCA (Network Configuration Assistant): is a GUI utility that simplifies the configuration of Oracle network components.
- NETMGR (Oracle Net Manager): is a more advanced and flexible tool compared to NETCA, providing a graphical interface for detailed configuration of Oracle Net Services.
- RMAN (Recovery Manager): A command-line interface for performing backup and recovery operations in Oracle databases.

2. Golden Gate Commands:
- GGSCI (GoldenGate Software Command Interface): Used for managing, configuring, and monitoring Oracle GoldenGate processes.
- OGGCA (Oracle GoldenGate Configuration Assistant): A command-line tool for configuring Oracle GoldenGate instances.
- Logdump: A utility for viewing and analyzing trail files generated by Oracle GoldenGate.
- DEFGEN (Definition File Generator): A command-line tool used to generate definition files in heterogeneous environments.

3. Oracle Grid Infra Commands:
- CRSCTL (Cluster Ready Services Control Utility): Used to manage Oracle Clusterware components.
- SRVCTL (Service Control): Used for managing Oracle RAC databases and other resources within the cluster.
- ASMCMD (ASM Command Line Utility): A command-line tool for managing Oracle ASM instances and disks.
- CLUVFY (Cluster Verification Utility): A tool for verifying the integrity and proper configuration of Oracle RAC and Oracle Grid Infrastructure.
- CRSSTAT: A utility that provides a summary of the current status of all cluster resources.
- OCRCONFIG: Used to manage the Oracle Cluster Registry (OCR).

4. Additional commands:
-dbcli (Database Command Line Interface): Used on Oracle OCI Cloud to apply patches and upgrade oracle software like database oracle home.
- EMCLI (Oracle Enterprise Manager CLI): Used to manage and automate Oracle Enterprise Manager operations via scripts.
- OPatch: A tool for applying and rolling back patches in Oracle software installations.
- ADRCI (Automatic Diagnostic Repository Command Interpreter): Used for managing diagnostic data such as alert logs, trace files, and incidents.
- ORAPWD (Oracle Password Utility): Used for creating and managing password files for Oracle databases.
- ORAPKI (Oracle Public Key Infrastructure): is a command-line utility provided by Oracle for managing security credentials.
- DGMGRL (Data Guard Manager Command-Line Interface): is the primary command-line interface for managing Oracle Data Guard configurations.



Saturday, August 10, 2024

Display Oracle RAC Cluster Name

 Below are different ways to know the RAC cluster name,

1. The command “cemutlo” provides cluster name and version.

$GI_HOME/bin/cemutlo [-n] [-w]

[oracle@rac1 ~]$ cemutlo -n
sami-rac-scan <—– This is the Cluster name.

2. $CRS_HOME/cdata/<cluster_name> directory

3. ocrdump
which will create a text file called OCRDUMPFILE open that file and look for this entry
+[SYSTEM.css.clustername]+ ORATEXT : crs_cluster In this case, “crs_cluster” is the cluster name.

4. gpnptool get
search for keyword “ClusterName

5. ASM SP File location
[root@rac1 ]# gpnptool getpval -asm_spf (or) SQL> show parameter spfile 
+DATA/<clusterName>/asmparameterfile/registry.253.783619900

Note: We cannot change the cluster name. 

The only way to change the cluster name is to reinstall the Clusterware and provide a new name to the cluster. 

Tuesday, July 30, 2024

IBM DB2 STOP and START

 #!/bin/bash

# Function to stop Db2
stop_db2() {
echo “Stopping Db2…”
db2stop
if [ $? -eq 0 ]; then
echo “Db2 stopped successfully.”
else
echo “Regular stop failed. Attempting forceful stop…”
db2stop force
if [ $? -eq 0 ]; then
echo “Db2 stopped forcefully.”
else
echo “Failed to stop Db2.”
fi
fi
}

# Function to start Db2
start_db2() {
echo “Starting Db2…”
db2start
if [ $? -eq 0 ]; then
echo “Db2 started successfully.”
else
echo “Failed to start Db2.”
fi
}

# Main script
if [ “$1” == “stop” ]; then
stop_db2
elif [ “$1” == “start” ]; then
start_db2
else
echo “Usage: $0 [stop|start]”
exit 1
fi

Install DB2 V10.5 using GUI

 Table of Content:

1. Hardware Requirements

2. Verify OS version

3. Download DB2 software

4. Untar Software

5. DB2 Installation Prerequisites

6. Set the DISPLAY Environment

7. Invoke ./db2setup

8. Validation

9. Verification

1. Hardware Requirements

2. Verify OS version

[root@pcs1 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
[root@pcs1 ~]#

3. Download Software

Download DB2 from www.ibm.com


4. Untar Software

[root@pcs1 ~]# mkdir -p /u01/IBM/db2
[root@pcs1 stage]# tar -xvf v10.5fp10_linuxx64_server_t.tar.gz -C /u01/IBM/db2

[root@pcs1 stage]# cd /u01/IBM/db2
[root@pcs1 db2]# ls -ltr
total 4
drwxr-xr-x. 5 root root 4096 Jul  4  2018 server_t
[root@pcs1 db2]# cd server_t
[root@pcs1 server_t]# ls -ltr
total 116
drwxr-xr-x.  4 root root    84 Jul  4  2018 nlpack
-r-xr-xr-x.  1 bin  bin   5642 Jul  4  2018 db2prereqcheck
-r-xr-xr-x.  1 bin  bin   5798 Jul  4  2018 db2_deinstall
-r-xr-xr-x.  1 bin  bin   5650 Jul  4  2018 db2setup
-r--r--r--.  1 bin  bin  41540 Jul  4  2018 db2checkCOL.tar.gz
-r-xr-xr-x.  1 bin  bin   5632 Jul  4  2018 db2ls
-r--r--r--.  1 bin  bin   4987 Jul  4  2018 db2checkCOL_readme.txt
-r-xr-xr-x.  1 bin  bin   5883 Jul  4  2018 db2ckupgrade
-r-xr-xr-x.  1 bin  bin   5668 Jul  4  2018 db2_install
-r-xr-xr-x.  1 bin  bin   5686 Jul  4  2018 installFixPack
drwxr-xr-x. 10 bin  bin   4096 Jul  4  2018 ibm_im
drwxr-xr-x.  6 bin  bin   4096 Jul  4  2018 db2
[root@pcs1 server_t]#


5. DB2 Installation Prerequisites

[root@pcs1 server_t]# ls -ltr db2prereqcheck
-r-xr-xr-x. 1 bin bin 5642 Jul  4  2018 db2prereqcheck
[root@pcs1 server_t]#
[root@pcs1 server_t]# ./db2prereqcheck
..............
..............
Summary of prerequisites that are not met on the current system:
   DBT3514W  The db2prereqcheck utility failed to find the following 32-bit library file: "/lib/libpam.so*".


DBT3514W  The db2prereqcheck utility failed to find the following 32-bit library file: "libstdc++.so.5".


DBT3563E  The db2prereqcheck utility determined that SELinux is enabled, which is not supported with GPFS.

[root@pcs1 server_t]#


6. Set the DISPLAY Environment

If you are using X emulation then set the DISPLAY environmental variable.

[root@pcs1 server_t]# export DISPLAY=192.168.2.1:0.0;


7. Invoke ./db2setup

[root@pcs1 server_t]# ls -ltr
total 116
drwxr-xr-x.  4 root root    84 Jul  4  2018 nlpack
-r-xr-xr-x.  1 bin  bin   5642 Jul  4  2018 db2prereqcheck
-r-xr-xr-x.  1 bin  bin   5798 Jul  4  2018 db2_deinstall
-r-xr-xr-x.  1 bin  bin   5650 Jul  4  2018 db2setup
-r--r--r--.  1 bin  bin  41540 Jul  4  2018 db2checkCOL.tar.gz
-r-xr-xr-x.  1 bin  bin   5632 Jul  4  2018 db2ls
-r--r--r--.  1 bin  bin   4987 Jul  4  2018 db2checkCOL_readme.txt
-r-xr-xr-x.  1 bin  bin   5883 Jul  4  2018 db2ckupgrade
-r-xr-xr-x.  1 bin  bin   5668 Jul  4  2018 db2_install
-r-xr-xr-x.  1 bin  bin   5686 Jul  4  2018 installFixPack
drwxr-xr-x. 10 bin  bin   4096 Jul  4  2018 ibm_im
drwxr-xr-x.  6 bin  bin   4096 Jul  4  2018 db2
[root@pcs1 server_t]#
[root@pcs1 server_t]#
[root@pcs1 server_t]# ./db2setup
Requirement not matched for DB2 database "Server" . Version: "10.5.0.10".

Summary of prerequisites that are not met on the current system:

   DBT3514W  The db2prereqcheck utility failed to find the following 32-bit library file: "/lib/libpam.so*".


DBT3514W  The db2prereqcheck utility failed to find the following 32-bit library file: "libstdc++.so.6".


DBI1190I  db2setup is preparing the DB2 Setup wizard which will guide
      you through the program setup process. Please wait.

8. Validation

[root@pcs1 server_t]# /u01/IBM/db2/V10.5/bin/db2val
DBI1379I  The db2val command is running. This can take several minutes.

DBI1335I  Installation file validation for the DB2 copy installed at
      /u01/IBM/db2/V10.5 was successful.

DBI1343I  The db2val command completed successfully. For details, see
      the log file /tmp/db2val-220423_131019.log.


[root@pcs1 server_t]#

9. Verification

[db2inst1@pcs1 ~]$ id
uid=54323(db2inst1) gid=101(db2iadm1) groups=101(db2iadm1)
[db2inst1@pcs1 ~]$
[db2inst1@pcs1 ~]$ db2level
DB21085I  This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL1005A" with level
identifier "060B010E".
Informational tokens are "DB2 v10.5.0.10", "s180615", "IP24053", and Fix Pack
"10".
Product is installed at "/u01/IBM/db2/V10.5".

[db2inst1@pcs1 ~]$
[db2inst1@pcs1 ~]$ db2ls

Install Path                       Level   Fix Pack   Special Install Number   Install Date                  Installer UID
---------------------------------------------------------------------------------------------------------------------
/u01/IBM/db2/V10.5              10.5.0.10       10                            Sat Apr 23 12:57:17 2022 +08             0
[db2inst1@pcs1 ~]$
[db2inst1@pcs1 ~]$ ps -ef | grep db2
root      2899     1  0 12:58 ?        00:00:00 db2wdog 0 [db2inst1]
db2inst1  2901  2899  0 12:58 ?        00:00:02 db2sysc 0 <---
root      2907  2899  0 12:58 ?        00:00:00 db2ckpwd 0
root      2908  2899  0 12:58 ?        00:00:00 db2ckpwd 0
root      2909  2899  0 12:58 ?        00:00:00 db2ckpwd 0
db2inst1  2911  2899  0 12:58 ?        00:00:00 db2vend (PD Vendor Process - 1) 0
db2inst1  2920  2899  0 12:58 ?        00:00:01 db2acd 0 ,0,0,0,1,0,0,0,0000,1,0,995db8,14,1e014,2,0,1,41fc0,0x210000000,0x210000000,1600000,30003,2,c0013
root     19016  6539  0 13:13 pts/1    00:00:00 su - db2inst1
db2inst1 19017 19016  0 13:13 pts/1    00:00:00 -bash
db2inst1 20146 19017  0 13:17 pts/1    00:00:00 ps -ef
db2inst1 20147 19017  0 13:17 pts/1    00:00:00 grep --color=auto db2
root     27033     1  0 12:57 ?        00:00:00 /u01/IBM/db2/V10.5/bin/db2fmcd
[db2inst1@pcs1 ~]$

[db2inst1@pcs1 ~]$ db2ilist
db2inst1
[db2inst1@pcs1 ~]$
[db2inst1@pcs1 ~]$ db2 get instance

 The current database manager instance is:  db2inst1

[db2inst1@pcs1 ~]$

[db2inst1@pcs1 ~]$ db2licm -l
Product name:                     "DB2 Advanced Enterprise Server Edition"
License type:                     "Trial"
Expiry date:                      "07/21/2022"
Product identifier:               "db2aese"
Version information:              "10.5"

[db2inst1@pcs1 ~]$

[db2inst1@pcs1 ~]$ db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 10.5.10

You can issue database manager commands and SQL statements from the command
prompt. For example:
    db2 => connect to sample
    db2 => bind sample.bnd

For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
 ? CATALOG DATABASE for help on the CATALOG DATABASE command
 ? CATALOG          for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 =>
db2 => quit
DB20000I  The QUIT command completed successfully.
[db2inst1@pcs1 ~]$
[db2inst1@pcs1 ~]$ db2 list db directory
SQL1031N  The database directory cannot be found on the indicated file system.
SQLSTATE=58031
[db2inst1@pcs1 ~]$

DB2 export and import

Caution: Your use of any information or materials on this website is entirely at your own risk. It is provided for educational purposes only. It has been tested individually; however, we do not guarantee that it will work for you. Ensure that you run it in your test environment before using.