Oracle DB Migration Test Cases
Step by step
Asfaw Gedamu
Download documents from:
https://t.me/paragonacademy
July 29,2023
Database migration can be very complex. Especially, the migration of bigger enterprise database
actually becomes a serious project that demands a serious planning and execution. Accordingly,
there are a number of factors that you will need to consider.
1. Assess the complexity of the migration. This includes identifying the number of schemas,
the number of tables and other objects in each schema, the dependencies between the schemas,
and the grants that have been granted to users and roles.
3. Develop a migration plan. The migration plan should include the following:
The steps that will be taken to migrate the data from Oracle to other databse (e.g. PostgreSQL.)
The tools and technologies that will be used for the migration.
3. The testing plan will be used to verify the success of the migration.
Migrate the data. This includes the following:
Migrating the data from the Oracle tables to the new DB tables.
Migrating the grants from Oracle to other DB.
Migrating the dependencies between the schemas.
4. Test the migration. This includes the following:
Testing the data to make sure that it has been migrated correctly.
Testing the grants to make sure that they have been migrated correctly.
Testing the dependencies to make sure that they have been migrated correctly.
5. Promote the new database to production. Once the migration has been tested and verified,
the new database can be promoted to production.
Starting with an assessment helps how many problems are going to have to be addressed. This
will help to ensure that the migration plan is realistic and that the migration is completed
successfully.
The testing plan is also an important part of the migration process. The test plan should be
designed to verify that the data has been migrated correctly and that the dependencies between
the schemas have been maintained.
With these points in mind, here are some Oracle Database test cases for FINACLE CBS on pre-
migration, during migration, and post-migration:
Pre-migration
• Check the table presence in the database schema.
SELECT table_name
FROM dba_tables;
• Check table naming convention.
SELECT table_name, owner
FROM dba_tables
ORDER BY table_name;
• Check the number of columns in a table.
SELECT count(*)
FROM dba_tab_columns
WHERE table_name = 'MY_TABLE';
• Check column names in a table.
SELECT column_name
FROM dba_tab_columns
WHERE table_name = 'MY_TABLE';
• Check the data types of the columns in a table.
SELECT column_name, data_type
FROM dba_tab_columns
WHERE table_name = 'MY_TABLE';
• Check the primary key constraints on a table.
SELECT constraint_name, constraint_type
FROM dba_constraints
WHERE table_name = 'MY_TABLE'
AND constraint_type = 'P';
• Check the foreign key constraints on a table.
SELECT constraint_name, constraint_type
FROM dba_constraints
WHERE table_name = 'MY_TABLE'
AND constraint_type = 'R';
Note: These are just a few examples of the commands and SQL statements that you can run
during pre-migration to check the tables in the database schema. You may need to add more
checks depending on your specific environment and requirements.
During migration
Here are some specific SQL statements that you can use to perform these tests
Check the progress of the migration:
• Use the v$session view to check the status of the migration sessions.
• Use the v$sql_monitor view to check the progress of individual SQL statements.
• Use the dba_jobs view to check the status of the migration jobs.
SELECT *
FROM v$session
WHERE program = 'FINACLE_CBS_MIGRATION';
SELECT sql_id, status, progress
FROM v$sql_monitor;
SELECT job_name, status
FROM dba_jobs
WHERE job_name LIKE '%FINACLE_CBS_MIGRATION%';
Check the logs for any errors:
• Check the migration logs for any errors.
• Use the dbms_output package to capture any errors that are generated during the
migration.
SELECT *
FROM dba_errors
WHERE error_type = 'MIGRATION';
Verify the integrity of the data:
• Use the dbms_stats package to collect statistics on the migrated data.
• Use the dbms_goldengate package to verify the integrity of the data.
EXEC dbms_stats.gather_table_stats('MY_TABLE');
EXEC dbms_goldengate.verify_table('MY_TABLE');
Note: These are just a few examples of Oracle Database test cases for FINACLE CBS on
during migration. You may need to add more test cases depending on your specific environment
and requirements.
Post-migration
Here are some Oracle Database test cases for FINACLE CBS on post-migration:
Check that all the tables and columns are migrated successfully:
• Use the dba_tables view to check the list of tables in the database.
• Use the dba_tab_columns view to check the list of columns in each table.
SELECT *
FROM dba_tables;
SELECT *
FROM dba_tab_columns;
Check that all the primary key and foreign key constraints are migrated successfully:
• Use the dba_constraints view to check the list of constraints in the database.
• Use the dba_primary_keys view to check the list of primary keys in the database.
• Use the dba_foreign_keys view to check the list of foreign keys in the database.
Here are some specific examples of how you can use these views to check the constraints:
# Check the status of the primary key constraint for the MY_TABLE table
SELECT status
FROM dba_constraints
WHERE table_name = 'MY_TABLE'
AND constraint_type = 'P';
# Check the columns that are included in the primary key for the MY_TABLE
table
SELECT column_name
FROM dba_primary_keys
WHERE table_name = 'MY_TABLE';
# Check the referenced table for the foreign key constraint MY_FK
SELECT referenced_table_name
FROM dba_foreign_keys
WHERE constraint_name = 'MY_FK';
Note: These are just a few examples of how you can use the dba_constraints,
dba_primary_keys, and dba_foreign_keys views to check the constraints in your database. You
may need to add more checks depending on your specific environment and requirements.
Verify the integrity of the data:
• Use the dbms_stats package to collect statistics on the migrated data.
• Use the dbms_goldengate package to verify the integrity of the data.
• Run a set of test queries to verify that the data is correct.
Here are some specific examples of how you can use these packages and queries to verify the
integrity of the data:
# Use the dbms_stats package to collect statistics on the MY_TABLE table
EXEC dbms_stats.gather_table_stats('MY_TABLE');
# Use the dbms_goldengate package to verify the integrity of the MY_TABLE
table
EXEC dbms_goldengate.verify_table('MY_TABLE');
# Run a query to count the number of rows in the MY_TABLE table
SELECT COUNT(*)
FROM MY_TABLE;
# Run a query to check the values in the CUSTOMER_ID column in the MY_TABLE
table
SELECT *
FROM MY_TABLE
WHERE CUSTOMER_ID = 123456789;
Note: these are just a few examples of how you can use the dbms_stats, dbms_goldengate, and
SQL queries to verify the integrity of the data. You may need to add more checks depending on
your specific environment and requirements.
Test the application to make sure that it is working properly after the migration:
• Run the application through its full test suite.
• Test the application with a variety of data.
• Test the application with different users.
Run the application through its full test suite:
• Run the application's test suite as it is currently configured.
• If the application has a regression testing suite, run that as well.
Run the application's test suite as it is currently configured:
• If the application has a command-line interface, you can run the test suite from the
command line.
• If the application has a graphical user interface, you can run the test suite from the GUI.
Here are some specific examples of how you can run the test suite:
# Run the application's test suite from the command line
./run_tests.sh
# Run the application's regression testing suite from the command line
./run_regression_tests.sh
# Run the application's test suite from the GUI
Open the application's GUI.
Click on the "Test" menu.
Select "Run All Tests".
The contents of ./run_tests.sh can vary depending on the specific application and its test
suite. However, here is a basic example of what the script might contain:
#!/bin/bash
# Set the environment variables
export APP_HOME=/path/to/application
export TEST_HOME=/path/to/test/suite
# Run the test suite
cd $TEST_HOME
./run_all_tests.sh
This script will first set the environment variables APP_HOME and TEST_HOME. These variables tell
the script where to find the application and the test suite.
Next, the script will change to the directory where the test suite is located. Then, it will run the
run_all_tests.sh script, which will execute all of the tests in the suite.
The contents of run_all_tests.sh can vary depending on the specific test suite.
However, here is a basic example of what the script might contain:
#!/bin/bash
# Import the necessary modules
import unittest
# Create a list of all the test cases
tests = [
TestCase1,
TestCase2,
TestCase3,
]
# Run all of the tests
for testcase in tests:
testcase.run()
# Print the results of the tests
print("All tests passed")
This script will first import the unittest module. This module provides the necessary
functions for running tests.
Next, the script will create a list of all the test cases. The test cases are represented by
objects that inherit from the TestCase class.
Finally, the script will run all of the tests. For each test case, the script will call the run()
method. The run() method will execute the test case and report the results.
The specific test cases that are used in the script will vary depending on the application.
However, this basic example should give you a good starting point for creating your own
run_all_tests.sh script.
The specific commands that are used to run the tests will vary depending on the test suite.
However, this basic example should give you a good starting point for creating your own
run_tests.sh script.
Here are some additional things to keep in mind when creating your run_tests.sh script:
• The script should be executable. You can make it executable by running the chmod +x
./run_tests.sh command.
• The script should be placed in the same directory as the test suite.
• The script should be able to be run from any directory.
• The script should be able to handle errors gracefully.
If the application has a regression testing suite, run that as well:
• A regression testing suite is a set of tests that are designed to verify that the application
still works after it has been changed.
• You can run the regression testing suite from the command line or from the GUI.
The contents of ./run_regression_tests.sh can vary depending on the specific application
and its regression testing suite. However, here is a basic example of what the script might
contain:
#!/bin/bash
# Set the environment variables
export APP_HOME=/path/to/application
export TEST_HOME=/path/to/regression/test/suite
# Run the regression test suite
cd $TEST_HOME
./run_all_regression_tests.sh
This script will first set the environment variables APP_HOME and TEST_HOME. These variables tell
the script where to find the application and the regression test suite.
Next, the script will change to the directory where the regression test suite is located. Then, it
will run the run_all_regression_tests.sh script, which will execute all of the regression
tests in the suite.
The contents of run_all_regression_tests.sh can vary depending on the specific
regression test suite. However, here is a basic example of what the script might contain:
#!/bin/bash
# Import the necessary modules
import unittest
# Create a list of all the regression test cases
regression_tests = [
RegressionTestCase1,
RegressionTestCase2,
RegressionTestCase3,
]
# Run all of the regression tests
for regression_testcase in regression_tests:
regression_testcase.run()
# Print the results of the tests
print("All regression tests passed")
The specific commands that are used to run the tests will vary depending on the regression test
suite. However, this basic example should give you a good starting point for creating your own
run_regression_tests.sh script.
Here are some additional things to keep in mind when creating your run_regression_tests.sh
script:
• The script should be executable. You can make it executable by running the chmod +x
./run_regression_tests.sh command.
• The script should be placed in the same directory as the regression test suite.
• The script should be able to be run from any directory.
• The script should be able to handle errors gracefully.
Test the application with a variety of data:
• Test the application with different types of data, such as numeric data, character data, and
date data.
• Test the application with different sizes of data, such as small amounts of data and large
amounts of data.
Test the application with different users:
• Test the application with different types of users, such as regular users and privileged
users.
• Test the application with different permissions, such as read-only permissions and write
permissions.
Here are some specific commands and SQL statements that you can use to perform these tests:
# Run the application's test suite
./run_tests.sh
# Test the application with different types of data
SELECT *
FROM MY_TABLE
WHERE data_type = 'NUMBER';
SELECT *
FROM MY_TABLE
WHERE data_type = 'VARCHAR2';
SELECT *
FROM MY_TABLE
WHERE data_type = 'DATE';
# Test the application with different sizes of data
SELECT *
FROM MY_TABLE
ORDER BY RAND()
LIMIT 100;
SELECT *
FROM MY_TABLE
ORDER BY RAND()
LIMIT 10000;
# Test the application with different users
CONNECT MY_USER/MY_PASSWORD;
SELECT *
FROM MY_TABLE;
CONNECT OTHER_USER/OTHER_PASSWORD;
SELECT *
FROM MY_TABLE;
Note: these are just a few examples of commands and SQL statements that you can use to
test the application to make sure that it is working properly after the migration. You may need to
add more tests depending on your specific environment and requirements.
