Welcome to our blog post series covering the typical conversion issues of AWS Schema Conversion Tool (SCT). DBBest team has a vast experience in database migration area, so we decided to start the blog post series covering the most common conversion issues of AWS SCT. Each blog post will be devoted to a certain action item and will povide specific solution or a workaround for a problem.
Below you can find the table of contents for blog posts, related to the typical AWS SCT conversion issues. We will update the list in this post for new SCT issues posts. For regular users of SCT feel free to bookmark this post to keep an eye out for new tips!
You may use an AWS Schema Conversion Tool (SCT) during your database migration projects to automate the conversion process. SCT performs a huge part of code conversion automatically, but your source code may still include some problem areas that may cause some sort of issues, needed to be resolved manually. In this case, SCT generates the corresponding action item and provides there some general recommendations on how you can address this current issue.
To explore the action items, occurred in your conversion project, select View — Assessment Report View and switch to the Action Items tab.
While AWS SCT serves as a great aid, you are likely to have many quesitons and issues during your migration project. Make sure to check out our new AWS Schema Conversion Tool Jumpstart offer to get you up and running fast for your database migration projects.
SQL Server has several different ways of implementing the same behavior as an Oracle materialized view. SSMA cannot understand the original optimization reason for why the application needed the materialized view, so SSMA flags certain conditions as an error. This blog post discusses error O2SS0522 where the Oracle materialized view includes FLOAT columns, WHERE or GROUP BY clauses, subqueries, UNION, MINUS, INTERSECT, etc.
Currently SQL Server Migration Assistant (SSMA) for Oracle converts materialized views to SQL Server indexed views. While converting a materialized view, SSMA creates necessary unique clustered index on the view in SQL Server. Also, SSMA adds WITH SCHEMABINDING option to the CREATE VIEW statement. So, if the source Oracle’s materialized view contains elements that are prohibited in the SELECT statement of the indexed view, the conversion will fail with an error.
Let us try to convert materialized view with a float type column. SSMA will generate the following error message: «O2SS0522: Materialized view with float type can’t be converted (restriction)». Below we will provide some useful workarounds and show how you can successfully avoid this error and convert Oracle’s pivot operation.
Running your database migration projects, you may have already noticed that AWS Schema Conversion Tool (SCT) automatically generates an additional schema called extension pack. This schema emulates the system functions and specific features of the source database in your target DB instance.
In the following video, we demonstrate how to apply this extension pack to the OLTP database. And in our future blog posts we will talk about working with extension pack for data warehouses.
An international healthcare company felt the urge to migrate core components of their application initially to Azure Infrastructure-as-a-Service (IaaS) with a long-term goal of transferring the solution to Azure Platform-as-a-Service (PaaS).
We came up with a solution that automates the ‘lift and shift’ migration of their existing Linux-based MongoDB Cluster (dozens of virtual machines) to Azure IaaS. We created the cloud automation script that allows not only to deploy the customer’s system but also to upgrade and scale it in the cloud, thus making the whole system cost-effective and improving its performance.
Watch the following video to find out more about our technical approach to the MongoDB Cluster Deployment automation.
Continue reading to learn more technical stuff about this interesting project.
One of the leading US healthcare organizations needed to upgrade their health record system in an effort to drive down costs while enabling new capabilities. We replaced the customer’s original Oracle database with SQL Server database to build a scalable and secure architecture. That task was challenging due to the huge volume of data along with very large tables aggregated in the original database.
As a result, the customer got the modern, secure, and less expensive platform. Please check how we migrated the custom database in the following video.
Have you ever asked yourself, wouldn’t it be cool if I had a smartphone application that would show me how a piece of equipment will look on my shop floor before buying? We’re proud to introduce you to an augmented reality iOS application developed by DB Best. This application displays a selected 3D model of production equipment on the screen of iPhone or iPad, adding it to the live camera picture. So, you can explore, how the machinery will fit into your production facilities after the installation. Also, you can discover the selected production equipment in details by zooming and rotating the model on the screen of your smartphone or tablet.
Here’s what our customer had to share:
I researched three companies when making a decision of who I should choose to develop and design my app, Mechanical Reality. DB Best included all the necessary information for me to make a decision and presented the information in a timely manner. Julia’s constant communication between myself and her team made it really easy to make a decision to use DB Best.
DB Best finished in the requested deadline, while working closely with me to meet my request.
I will continue to use DB Best for existing and future projects. They went beyond my needs!
Watch the following video to learn more about the application features.
DB Best can create a similar application for you under a cost-effective and high-reliable project. We can customize an augmented reality iOS app considering your requirements in a very short time frame. Contact us now to learn how we can deliver an outstanding mobile product to expand your business. Find more details about this cool application below. Read the rest of this entry »
Oracle’s SELECT INTO statement with BULK COLLECT clause allows you to retrieve an entire result set and store it in a PL/SQL collection type variable in a single operation. This approach allows to avoid the use of a loop statement to retrieve one result row at a time, thus making the code compact and effective.
MySQL doesn’t support the BULK COLLECT INTO operation, so, SCT can not convert the source Oracle code correctly. When you try to convert the source code that contains the SELECT INTO statement with BULK COLLECT Clause, SCT will generate the following message “140 — Severity CRITICAL – MySQL doesn’t support BULK COLLECT INTO. You can try to include all of the fields from your table in an INTO clause.”
The right approach to solve the occurred issue implies creating the loop statement to extract the results row-by-row.
Migrating data warehouses to Amazon Redshift represents a serious challenges when you consider what it takes to transfer huge amounts of data in parallel. On February 16, 2017, Amazon released version 1.0.600 of AWS Schema Conversion Tool (SCT). This release brings the support of Data Migration Agents. Now you can effectively extract data from Oracle and Teradata data warehouses and prepare it for use with Amazon Redshift.
In the following video, we will demonstrate the typical workflow of using the Data Migration Agents to extract data and upload it to Amazon Redshift using the S3 Bucket as a data loading zone.
A financial service software provider needed to upgrade their customer facing applications with a new database engine in addition to the existing database. They chose SQL Server as a new database engine because of the high availability features such as Always On along with Transparent Data Encryption to secure the data in the new database.
We came up with a way to create an identical version of their existing Sybase ASE database running in SQL Server environment and performed some code unification that allowed the Power Builder front-end application to interact with both databases. Thus, the customer’s system now meets the rigorous high availability and encryption industry standards.
The following video shows how we performed the application remediation and the database code unification.
Oracle 11g introduced pivot operation that allows writing cross tabulation (also called transposed, crosstab and matrix) queries that rotate rows into columns and aggregate results. Pivot rotates a table-valued expression by turning the unique values from one column in the expression into multiple columns in the output and performs aggregations where they are required on any remaining column values that you want to get in the final output. SQL Server Migration Assistant (SSMA) for Oracle cannot correctly parse the pivot operator and generates the following error message: «Error O2SS0004: Unparsed SQL». In this blog post we will provide some useful workarounds and show how you can successfully avoid this error and convert Oracle’s pivot operation.
Oracle allows you to create foreign key for table using columns with different data types. But SQL Server Migration Assistant (SSMA) for Oracle cannot convert them to SQL Server correctly because SQL Server doesn’t support the foreign keys that use columns with different data types. So, when you try to convert the original code that includes the foreign key with the columns of different data types, SSMA will generate the following error message: «Error O2SS0231: Foreign keys with different types of columns and referenced columns cannot be converted». In this blog post we will show how you can address this error and eliminate this conversion issue from your project.