Monday, July 17, 2023

High Level Oracle Database Migration Plan – Datapump

 Pre-Migration Phase: No Downtime

  • Review the Source database configuration
  • Build target environment in AWS Cloud
  • Prepare target database 



 Migration Phase (cutover) : Downtime

  • Source database backup 
  • Transfer the backup to target
  • Import backup in target database
  • Validate the migrated database


 


Post-Migration Phase : Downtime

  • Handover database to application team
  • Application team start validation
  • Decide Go-Live /No Go-Live
  • Target database golden backup
  • Release database and application


 


Note : Normally good for small database 

About the Author : Anurag Pandey | Database cloud Architect | Oracle | SQL Server | PostgreSQL | AI and Data Platform Enthusiast

Anurag Pandey is a Database Architect with expertise in Oracle, PostgreSQL, SQL Server, Linux, and enterprise database platforms and specializes in database architecture, performance tuning, high availability, disaster recovery, cloud modernization, and operational excellence. With extensive experience in enterprise-scale environments, Anurag is passionate about leveraging AI, automation, and modern data platforms to improve reliability, scalability, and business outcomes. He actively contributes to technical communities through knowledge sharing, architecture guidance, and thought leadership in database and data engineering domains.

Follow more articles at

Visit Blog

High Level Maria DB Migration Plan

Pre-migration Phase (No -downtime)

  • Validate source and target database versions and engines.
  • Identify hardware requirements for the target server instance.
  • Identify storage requirements (storage type and capacity).
  • Choose the proper instance type based on capacity, storage features, and network features.
  • Identify the network access security requirements (firewall, port etc. ) for source and target databases.
  • Prepare target database
  • Configure and start an Amazon RDS DB instance running MariaDB.


 

Migration Phase (downtime)

  • Using native tools to migrate database objects and data.
  • In the source database, use mysqldump or mariadb-dump to create an output file that contains database objects and data.
  • Transfer the backup to target (AWS RDS)
  • In the target database, use mysql or mariadb to restore the data.
  • Validate the migrated database.


 Post-migration Phase (downtime)

  • Handover database to application team
  • Switch the application clients over to the new migration database in AWS RDS .
  • Application team start validation
  • Decide Go-Live /No Go-Live
  • Target database golden backup
  • Release database and application

Rollback Plan 

  • Start source database (Assume no data chnage on target database  after migration)
  • Connect & validate Application with source database 

About the Author : Anurag Pandey | Database cloud Architect | Oracle | SQL Server | PostgreSQL | AI and Data Platform Enthusiast

Anurag Pandey is a Database Architect with expertise in Oracle, PostgreSQL, SQL Server, Linux, and enterprise database platforms and specializes in database architecture, performance tuning, high availability, disaster recovery, cloud modernization, and operational excellence. With extensive experience in enterprise-scale environments, Anurag is passionate about leveraging AI, automation, and modern data platforms to improve reliability, scalability, and business outcomes. He actively contributes to technical communities through knowledge sharing, architecture guidance, and thought leadership in database and data engineering domains.

Follow more articles at

Visit Blog

Sunday, July 16, 2023

What Is a RACI Matrix ?

What Is a RACI Matrix ?


RACI matirix is very important when we are working on project  and this helps to align  who is reposible for what .



Like who will take decision , who will resposible for technical task , what resposiblity of cutomer and what information needs to share with custmers etc . 



R  => (Responsible)  : This member is resposible to taks done ---- like create infrastructure goes to infra team - Person1 ,Person2

A  => (Accountable) : This member is taking decision and ensure everythig is aligned and meet all standards ----which tool going to use for database assessment goes to db team -  Person2,Person1

C  => (Consulted) : Share the outcome and should be meet all criteria with input & feedback to improve the business process  - Person 3

I  = > (Informed) : Any other team ,team memebers, stakeholder who needs to informed about project status,progress ,blockers  etc -  Person 4 , Person 5





About the Author : Anurag Pandey | Database cloud Architect | Oracle | SQL Server | PostgreSQL | AI and Data Platform Enthusiast

Anurag Pandey is a Database Architect with expertise in Oracle, PostgreSQL, SQL Server, Linux, and enterprise database platforms and specializes in database architecture, performance tuning, high availability, disaster recovery, cloud modernization, and operational excellence. With extensive experience in enterprise-scale environments, Anurag is passionate about leveraging AI, automation, and modern data platforms to improve reliability, scalability, and business outcomes. He actively contributes to technical communities through knowledge sharing, architecture guidance, and thought leadership in database and data engineering domains.

Follow more articles at

Visit Blog

Oracle Database Deep Health Check Checklist

Oracle Database Deep Health Check Checklist Recommended assessment levels Level Purpose Typical scope L1 Operational health Availability, sp...