Oksana Eremenko

Technical Lead

Blog posts
Data Store
Creating and managing database snapshots using the DB Best Migration Platform
08 Nov 2019

We continue covering the core features of the DB Best Migration Platform. In this blog post, we will talk about the Data Store module that allows for creating and using database snapshots. The DB Best Migration Platform creates snapshots of all data or selected tables. We consider the database snapshot as a golden copy of the source data. The DB Best Migration Platform then uses this golden copy to restore data when you need it. Why do you need a golden copy? A database migration or upgrade project includes many steps where your data changes significantly. These steps include: Database schema changes Data migration Tests execution Before each...

testing code changes
How to test breaking changes and new features during the SQL Server upgrade
07 Nov 2019

Database upgrade is inevitable if you’re running aging versions of your databases. Alongside with cool new features, the upgrade brings some code changes. Regardless of the severity of these code updates, you need a proven solution to test these code changes. Let us consider a following case: after upgrading a SQL Server 2008 database to SQL Server 2017, we also updated the SQL code in the database to meet the new standards. Now we need to test this application and make sure that it works like before. Are you familiar with this challenge? If the answer is yes, then you will be happy to learn more about a proven, fully automated DB Best ...

Oracle virtual columns SQL Server
Converting Oracle virtual columns to Microsoft SQL Server
16 Sep 2019

In Oracle, you can specify virtual columns in a table definition. Oracle Database doesn’t store these virtual columns on the disk. Instead, the values of Oracle virtual columns are always calculated automatically. Oracle uses a set of expressions or functions to derive the values in the virtual column based on the values of other columns. SQL Server does have computed columns on a table that provides support similar to Oracle’s virtual columns. By default, SQL Server does not store these columns in the table unless you mark them as persisted. Making the calculated column persisted is an optimization in SQL Server that Oracle doesn...

naming convention
Defining a naming convention in Oracle to SQL Server migrations
17 Jul 2019

When migrating Oracle databases to Microsoft SQL Server, you need to define a naming convention for the conversion of packaged procedures and functions. This step is as important as setting the schema mapping and data type mapping. This is an architecture-level decision that you should make at the very beginning of your migration project. Now, we will talk about the importance of this decision and the possible issues it may cause. The problem By default, SQL Server Migrating Assistant (SSMA) uses the following rule to form the names of converted procedures and functions. Basically, SSMA combines the name of the Oracle package and the procedur...

Schema mapping in Oracle to SQL Server migrations
18 Jun 2019

When migrating Oracle databases to Microsoft SQL Server, the first problem you will face is mapping Oracle schema to SQL Server. You can hardly underestimate the importance of this architecture-level question because the wrong approach will lead to significant efforts in rewriting the code. The problem In Oracle, the database server contains an Oracle database and an Oracle instance. At the same time, every Oracle database contains schemas. By the way, you can learn more about the Oracle architecture here. Basically, a database is a physical component. Oracle does not use the database name as a part of the object’s name. Microsoft SQL S...

mapping Oracle data types
Use Caution When Mapping Oracle Data Types for Procedures and Function Parameters in SSMA
05 Jun 2019

When converting Oracle database code to Microsoft SQL Server, I often face the problem of correctly mapping Oracle data types to SQL Server data types. I regularly use SQL Server Migration Assistant (SSMA) to automate Oracle database code conversion to SQL Server. However, SSMA’s default data type mapping for Oracle procedure and function parameters uses the maximum possible size for each specific data type to prevent data loss. This approach causes unintended consequences with application code. The Problem In Oracle, you cannot specify the length, precision, scale of procedure, or function parameters. For example, you can use VARCHAR2 data...