Tag Archives: Oracle

Why Companies Are Moving Their Analytics to Oracle Cloud


More and more organizations are moving their analytics to the cloud—and Oracle is one of the most popular destinations. In a November 2020 ranking by Cloud Wars, Oracle was the second fastest-growing cloud vendor with an estimated quarterly revenue growth of 33 percent, behind only Google Cloud.

Looking to move your own analytics workflows to Oracle Cloud? As an Oracle Platinum Partner, Datavail has the skills and experience that companies need to make their next Oracle cloud analytics migration a success. Below, we will go over the benefits of running analytics in the Oracle Cloud, as well as some tips, tricks, and best practices for an Oracle cloud analytics migration.

Data Architecture

Source: https://docs.oracle.com/en/solutions/oci-curated-analysis/img/analysis-enterprise-and-streamed-data-architecture.png

The Benefits of Analytics on Oracle Cloud

Choosing the right cloud analytics partner is an essential part of a successful migration—so why Oracle Cloud? Migrating analytics to the Oracle cloud has the following benefits:

  • Lower IT costs: By saving money on expenses such as on-premises hardware, software licenses, and ongoing support and maintenance, many organizations find that cloud analytics is significantly more cost-effective.
  • Increased scalability and flexibility: Instead of running up against hardware constraints, organizations can make their analytics workloads more scalable and flexible by migrating to the cloud. Oracle Cloud Analytics makes it easy for users to scale their usage of Oracle Compute Units (OCPUs) up or down as necessary.
  • Data backup and business continuity: Backing up your business-critical information using Oracle Database Backup Cloud Service is essential for recovering quickly from data loss or disaster.

Tips and Tricks for Moving Analytics to Oracle Cloud

While there are many advantages of Oracle cloud analytics, moving your analytics platform to the cloud is not as easy as just snapping your fingers. Below, we offer some advice and best practices for an Oracle cloud analytics migration.

  1. Start simple

    The Oracle cloud ecosystem is vast, encompassing a wide range of services—just getting started can be intimidating and confusing. By starting small and simple with a pilot project, you can rack up a few “quick wins” that will convince key stakeholders of the benefits of an Oracle cloud migration.

  2. Take full advantage of the Oracle ecosystem

    That said, there is no shortage of synergies in the Oracle ecosystem that your organization can realize when you do ramp up your use of the Oracle cloud.

    One of Datavail’s clients, a healthcare and pharmaceutical company, was originally facing substantial barriers to effective data management and reporting. Although the client was using Oracle NetSuite cloud software for enterprise resource planning (ERP), the software’s output was simply dumped in Excel.

    Datavail helped the client build a scalable financial reporting repository in Oracle Analytics Cloud (OAC) that allows for ad hoc queries and drill-through analyses, getting smarter business insights from their data. In addition, the client now uses other Oracle tools such as Oracle Smart View and Oracle Data Visualization Desktop (DVD) for sharing and visualizing the outputs of their ETL process.

  3. Use Oracle migration tools

    Oracle’s ecosystem also extends to its cloud migration tools. For one, Oracle offers cloning tools for “lift and shift” migrations that copy data and applications to the cloud without modification. Meanwhile, Oracle GoldenGate Cloud Service is used for real-time replication of information mission-critical databases that can’t suffer downtime during the migration. The right Oracle migration partner can help advise you on the steps to take and the best tools to use throughout your move.

How Datavail Can Help

Datavail is an Oracle Partner, with years of experience helping businesses migrate to the Oracle cloud. We have the knowledge and skillset to make your next Oracle cloud migration a success. Our suite of Oracle cloud migration services includes:

  • Selecting the right cloud technologies for your business.
  • Completing a cloud readiness assessment of your organization.
  • Developing a cloud migration roadmap with an appropriate timeline.
  • Creating a total cost of ownership (TCO) estimate and deploying a proof of concept.
  • Uplifting analytics solutions from on-premises to the cloud.
  • Providing ongoing cloud support, maintenance, and management.


Want to see the benefits of moving your analytics to Oracle Cloud for yourself? Get in touch with Datavail’s team of cloud migration experts today for a chat about your business needs and objectives—or download our white paper “Across the Continent with Cloud Analytics” to see how 8 of our clients have leveraged cloud analytics to their advantage.

The post Why Companies Are Moving Their Analytics to Oracle Cloud appeared first on Datavail.

5 Reasons to Migrate Oracle Applications to Azure


As the war for cloud customers continues between ‘as a service’ vendors both large and small, Microsoft Azure continues to maintain its stronghold. With an all-inclusive offering of IaaS, SaaS, and PaaS, more than 50 active regions around the world, and an appealing free 12 months of service for new customers (restrictions apply), Azure is an appealing solution for companies across the globe.


This story is true for customers looking for an IaaS platform for Oracle applications as well. From Oracle EBS to JD Edwards to PeopleSoft, Azure can support the critical applications that drive your business in a hybrid or fully cloud hosted environment. Here are five reasons to consider moving your Oracle applications to Azure.

1) High Availability

This is one of the top reasons companies choose Microsoft Azure. Compared to other options on the market, Azure has the widest range of availability zones across the globe, offering a Service Level Agreement (SLA) of 99.95%. Each of these zones is made up of individual data centers that function interdependently so that if one zone experiences an unexpected disaster, the other zones can pick up the slack, keeping your data flowing and your business running. If you are running Oracle financial, supply chain, or retail applications that require near-100% uptime, having availability zones that reduce the impact of a failure are a must-have.

2) Scalability

As your business grows, so will your data – and likely so will your application investments. Azure has the ability to host petabytes of data. But even if you’re not there yet, hyper-threaded virtual machines feature up to 128 vCPUs and 6 TB of memory. In addition, with Azure infrastructure flexibility you will always have the storage and compute resources you need, including Azure Disk Storage which offers secure, persistent, and cost-friendly SSD options that can support any and all of your Oracle applications.

3) Disaster Recovery

Reducing downtime and implementing effective disaster recovery is at the forefront of every IT manager’s mind. Azure’s disaster recovery solutions can be integrated with your existing on-premises solutions so you don’t necessarily need to reinvent the wheel once you migrate your Oracle applications. Regardless, the interface for Azure Backup and Azure Site Recovery makes it simple to define policies to natively protect, monitor, and manage enterprise workloads.

You also have access to Azure Site Recovery which will enable you to manage disaster recovery for Oracle Linux VMs and on-premises or physical servers that might be supporting your applications.

4) Cost Reduction

Did we mention that Azure is free for 12 months for new customers? This gives you a chance to take it for a test drive before committing for the long term. But if you’re thinking you need to go all-in or not at all, you can save on licensing costs with Azure constrained-core virtual machines that are optimized specifically for Oracle workloads. You can also save a chunk of change with predictable workloads – reserve resources in advance with Azure Reserved VM Instances. Finally, Azure offers three years of extended security updates for Windows 2008 and 2008 R2 for free when you migrate.

5) Analytics & Insights

If you’re at the forefront of your industry and want to leverage innovations like predictive analytics, machine learning, and artificial intelligence to glean data-driven insights from your Oracle applications, Azure has a host of tools for you.

  • Build data lakes with Azure Data Lake Storage
  • Bring limitless scale and powerful insights to the table with Azure Synapse Analytics
  • Model and visualize data with Power BI
  • Ingest, prepare, and transform your data with Azure Data Factory

Final Thoughts

There are many more reasons to migrate to Azure, but these are the top five benefits of moving your Oracle applications to this top-rated cloud platform. If availability, scalability, cost reduction, and analytics are prime motivators for your organization, it might be time to make the move.

Of course, migrations are not simple undertakings and sometimes it helps to know that other companies have crossed the same territory. To learn about what an Oracle EBS to Azure migration might look like, download our white paper, “Fast Food Chain Completes Successful Oracle EBS Migration to Azure.” You’ll get the details on why this company migrated, how they did it, and the benefits they received.

The post 5 Reasons to Migrate Oracle Applications to Azure appeared first on Datavail.

How to Achieve Success During an Oracle to MariaDB Migration


MariaDB is a powerful open-source database technology that offers a range of enterprise-grade features and benefits, making it an attractive migration option for organizations using Oracle. However, you need to develop a comprehensive Oracle migration plan for a successful move. Here are some lessons Datavail has learned over thousands of database migrations.

Assess Your Cost Savings

Migrating from Oracle to MariaDB is a popular way for organizations to reduce their costs because of high expenses associated with licensing, add-ons, and long lead times on feature requests. According to MariaDB, “the total cost of Oracle is 84x higher than the MariaDB Platform, and organizations can save over $9 million after three years by choosing the MariaDB Platform.”

MariaDB offers an open-source model that lowers support costs and speeds up the process for feature requests. If you have the technical resources, you can develop custom database features and add them to MariaDB yourself. You also keep a comparable level of functionality, stability, and professional support when you migrate.

Perform Performance and Functional Testing at Scale

A successful and thorough proof of concept is an essential part of an Oracle to MariaDB migration. This proof of concept forms the basis of the migration plan and allows you to identify any roadblocks that could lead to failure. To get the most out of your testing, you should:

  • Use the same hardware as your production environment.
  • Emulate your application and database environment as much as possible.
  • Test against a product size data set.

Choose the Right Hardware Specifications

Trying to run MariaDB databases on non-database optimized hardware or those smaller than your Oracle environment can cause a performance bottleneck. When you select your MariaDB hardware, ensure that the following components have the right capabilities for your database load and application usage:

  • Types of drives
  • IOPS capacity
  • Drive mount options
  • RAID or other drive redundancy options
  • Memory size and type
  • CPU capacity

Leverage Oracle SQL Mode in MariaDB

One of the most significant advantages that MariaDB brings to the table over other open-source database options is its built-in Oracle SQL Mode. This feature helps companies quickly migrate from Oracle to MariaDB without completely changing their application code. Oracle Mode supports almost all PL/SQL syntax and commands. Most times, you end up making minimal code changes to make an application MariaDB compatible.

Understand MariaDB’s High Availability Architecture Gains

MariaDB’s overwhelmingly lower cost opens up more options for High Availability (HA) architecture. During one of our recent migration projects, our customer took a three-node DataGuard Architecture between two data centers and doubled their HA footprint with standard MariaDB Replication across six database servers.

Previously, this customer only had two nodes within the primary data center region. Any outages or planned maintenance left them vulnerable to outages or forced failover to the secondary datacenter if something happened to the remaining standing node.

The extra nodes added a layer of HA that helped the customer’s peace of mind and strengthened the availability and stability of their database architecture. This infrastructure also provides more scalability with MariaDB’s Maxscale Read-Write splitting between the nodes. For comparable architectures to Oracle RAC, MariaDB Galera Cluster provides multi-master clustering, which can combine with Replication to the disaster recovery site.

Adding Load Balancing Through MariaDB MaxScale

The MariaDB suite of products, included with the Enterprise license, offers the MaxScale advanced proxy server between the application and the database servers. This tool is full of useful and impressive features that make it an essential part of any MariaDB architecture, ranging from data masking to basic connection routing, automating database failover and replica promotion. MariaDB MaxScale 2.5 also introduces the MaxScale GUI, which gives you a graphic user interface for a more user-friendly experience compared to the command-line utility or working directly in the configuration file.

You can configure MaxScale with Query Caching using Native Caching, Redis, or MemCached, which can improve repetitive query speed by 8x and lighten the load on your database.

Read This Next

Going Open-Source: Making the Move to MariaDB from Oracle

Ready to start with your Oracle to MariaDB migration? This paper covers an overview of MariaDB, including key features and benefits, to help chart your course when making the migration to MariaDB.

The post How to Achieve Success During an Oracle to MariaDB Migration appeared first on Datavail.

Choosing the Right Configuration for an Oracle to MariaDB Migration


Your database’s configuration makes or breaks an Oracle to MariaDB migration project. You may end up with data loss, data corruption, bad performance, and poor query optimization without the proper settings. Here are the lessons Datavail has learned from thousands of database migrations.

MariaDB Built-in Features That Are Add-ons in Oracle

MariaDB has many features built into its Enterprise software that are only offered as add-ons in Oracle. As part of your Oracle migration project, it’s helpful to assess the features or settings that can best benefit your application.

For one of our customers, the flexibility and granularity of MariaDB’s permissions and user roles met their security needs far better than the Oracle add-on security packages they had purchased. The flexibility of using multiple table engines on a table-by-table basis is a unique feature in MariaDB and MySQL. Most implementations use the standard transactional InnoDB Engine; but reviewing your workload and table footprint helps determine if another engine may be better for some tables. Different engines can provide two to three times the compression, 10 times the IO write or store petabytes of data with powerful analytics speeds.

Evaluating Your Default Transaction Isolation Level

Consider the need to change from the default isolation level to better match the level on which your application was built. Oracle’s default Transaction Isolation Level is Read Committed. MariaDB’s default is Repeatable Read, which is fully ACID compliant and performs more locking, as all SELECTs within a transaction return the same result. If you use a level that the application isn’t written for, gap locks appear, and performance deteriorates.

Keeping Time Zones and Dates Consistent

Any migration should assess time zone settings at an application, database, and system level. Many legacy solutions are built in a specific time zone and face challenges with staying consistent, adding new time zones, and adjusting to daylight savings time changes.

During an Oracle to MariaDB migration, it’s imperative to assess the time zone impact because MariaDB doesn’t support the datatype “datetime with time zone” from Oracle. If this process isn’t handled correctly, time zones get stripped from the dataset. This data would be essentially useless with only a datetime stamp.

You can use Oracle Golden Gate to convert to the UTC time zone during the migration process to eliminate many of these issues. An alternative is adding a column to track the time zone, but this requires code changes.

Reviewing Your Indexes

Good indexing is critical to database performance, but DBMS systems approach query execution plans in different ways. Many legacy systems accumulate indexes over time that may no longer be relevant or helpful. Even if those indexes were created for active queries, MariaDB might choose a different index to execute that same query. Foreign Key Cascade on Delete behavior and Circular Foreign Keys are two other components that may cause performance issues if they’re not optimized for your current needs.

You also need to confirm that MariaDB supports your Oracle indexes. For example, it does not support Function-Based Indexes and Index Compression.

Review these indexes to determine if they’re beneficial in the new system or are just added overhead. When you’re reviewing slow queries on the migrated system, you can identify the need for any new indexes or indexes modified for MariaDB’s query optimizer.

During the actual migration process, performing the initial load without indexes on very large tables may improve the overall migration time. Importing bulk data will slow down when you have large tables with many indexes that need to be written to disk concurrently. Sometimes, using the ADD INDEX command after the initial load is beneficial.

Pay Attention to Sequences, Triggers, Stored Procs, and Jobs

Give special consideration and preparation to Objects that may behave differently across the databases or require syntax changes to migrate. MariaDB’s Oracle Mode helps with Non-ANSI Stored Procedure Construct and Stored Procedure Parameters; you should review and test all Stored Procs and triggers after converting the necessary syntax to confirm they still work and return the same data as Oracle. Some elements may not have equivalent objects or functions in MariaDB. For example, triggers in Oracle can fire on DML, DDL, or Database changes, but MariaDB triggers are only for DML changes. You can convert all Oracle scheduler jobs to run as MariaDB events.

Sequence Options are slightly different between Oracle and MariaDB. It’s vital to keep sequences disabled in MariaDB until after it becomes the master. The following Oracle Sequence Options don’t exist in MariaDB: NOORDER, NOKEEP, NOSCALE, and GLOBAL. You can use a basic sequence create statement on MariaDB to match the Sequence numbers on Oracle when you cutover. For example:


Check for Compatible CharSet and Collation Selections

If your migration tool or target database has a character set that doesn’t include all the characters used in Oracle, the migration ends up with corrupted or lost data. Similarly, choosing different collation settings in MariaDB than in Oracle could completely change query results against the MariaDB database, as the sorting and case sensitivity changes.

One of our customers didn’t review their character sets between their Oracle and MariaDB environments before their first migration attempt. They quickly found that the mismatched character sets caused errors in their Oracle GoldenGate migration, and certain characters in the data couldn’t migrate. Their source database had a universal charset utf8mb4, while their target was using Latin1. After changing the character set on the target database and its tables, the migration was completed successfully with no data loss.

Read This Next

Going Open-Source: Making the Move to MariaDB from Oracle

Want to learn more about the Oracle to MariaDB migration process? Download our white paper for more details. This paper will provide an overview of MariaDB, including key features and benefits, to help chart your course when making the migration to MariaDB.

The post Choosing the Right Configuration for an Oracle to MariaDB Migration appeared first on Datavail.

PostgreSQL vs. Oracle: Let’s Compare

Companies are faced with many options when deciding on a database management system. Discover the key differences between PostgreSQL vs. Oracle that will help you make an informed decision.

Types of Database Management Systems

Database management systems can be categorized as open-sourced or closed-source systems. Open-source means that anyone can download and modify the source code of the database technology for free. Closed-source means that the source code is private and inaccessible to everyone except the developers and authorized parties. You often need to pay a license fee to use closed-source software.

Open-sourced software has an active community of users and developers who can check the code for bugs, extend the software’s functionality, and often provide support for the solution. You have greater flexibility with open-sourced software, as you can customize it based on your company’s needs and have access to a large community for development resources.

Closed-source software offers less flexibility compared to open-source solutions, but it can make up for that through premium support options on-hand for emergencies, extensive training, and documentation resources, enterprise-grade security and stability, and less decision-making on the software versions to implement.

You can also find overlap between closed-source and open-source capabilities. For example, closed-source software may provide an add-on framework that allows third-party developers to extend functionality, while some open-source software can provide access to paid support solutions.

Key Differences Between PostgreSQL and Oracle

When you look at PostgreSQL vs. Oracle database management systems, the main difference between these two databases is that PostgreSQL is an open-source database, while Oracle is a closed database system. PostgreSQL is a free relational object-oriented database management system that is developed by volunteer developers worldwide. Oracle is a licensed commercial relational database management system.

Both database systems use similar concepts such as schemas, tablespaces and indices, but they diverge in areas such as replication and support. Let’s explore the ways that these two database systems handle vital operations.



  • High availability
  • Four levels of transactions: Read Uncommitted, Read Committed, Repeatable Read, Serializable
  • ACID-compliant



  • High availability
  • Higher transactions per second
  • More functional than PostgreSQL, but these functions come at a price premium
  • ACID-compliant



  • More scalable due to its open-source characteristics
  • Databases accommodate any volume of data
  • Cluster-based storage solutions allow for free expansion
  • Foster integrity during scalability operations with WAL files, although these files are limited to 16 MB



  • Have to spend more on infrastructure to carry out scalability operations, as the Standard edition only has four sockets, while the Enterprise edition offers more
  • Maintain data integrity with redo logs



  • Offers roles and inherited roles that allow developers to set permissions
  • Supports native SSL that assists in encrypting server communications
  • Provides extra access controls through SE-PostgreSQL that rely on SELinux’s security policy



  • More robust security features than PostgreSQL
  • Higher cost editions are required to access advanced security options
  • Resilient through security assessments, data protection, auditing, and monitoring
  • Provides excellent isolation solutions between pluggable databases and independent key encryption management



  • Active community that offers free online support via blogs, emails, code, and other channels
  • No phone number to call for emergencies
  • The cost to hire PostgreSQL community developers for premium support is less than a comparable Oracle specialist
  • Third-party support providers are also available, such as EnterpriseDB and 2nd Quadrant, that also offer their own PostgreSQL distribution



  • Expensive support
  • Large corporations have to hire Oracle consultants or depend on Oracle’s support, with a cost of up to 25 percent of the license fees
  • Emergency support is available by phone

Compatibility & Replication


  • High availability through Streaming Replication
  • Master-slave replication provides developers with flawless performance during backup, task allocation, and clustering
  • ORM framework support
  • Support for a larger group of APIs than Oracle, making it more compatible  with many applications, add-ons, and SQL environments
  • JDBC, ODBC, OLEDB and .Net library support



  • High availability through DataGuard
  • Master-slave replication provides developers with flawless performance during backup, task allocation, and clustering
  • Master-master replication
  • ORM framework support
  • JDBC, ODBC, OLEDB and .Net library support
  • Less API support than PostgreSQL

SQL Compliance


  • Less complex SQL Syntax, as PostgreSQL follows standard SQL
  • Non-standard built-in procedural extensions are available through pg/SQL
  • Pg/SQL is a less mature technology than Oracle’s, and is slower
  • Developers can use query handlers such as R and Python to write directly into the database



  • More complex SQL Syntax compared to PostgreSQL, as this database follows Oraclism
  • Non-standard built-in procedural extensions are available through PL/SQL
  • PL/SQL is a faster technology than pg/SQL

High Availability


  • PgPool in PostgreSQL Enterprise edition provides similar functionality to Oracle Real Application Clusters
  • Add nodes dynamically through horizontal scalability options
  • PgPool is not a built-in feature to PostgreSQL and requires many Clusterware tools to achieve similar functionality to Real Application Clusters



  • Databases can be shared across a pool of servers through Oracle Real Application Clusters
  • When one instance of failure occurs, the database can run on the remaining databases to offer continuous workflow management
  • Real Application Cluster is a built-in feature

Migration Tools


  • Offers many tools that support migration from Oracle
  • Ora2PG migrates large projects
  • Oracle_FDW moves schemas and data
  • Orafce ensures function compatibility
  • PGREPLAY is a stress testing tool that can be hacked to stress test large databases
  • For migrating code, third-party tools such as the AWS Schema Conversion Tool work well
  • Moving huge Oracle databases to PostgreSQL can consume significant resources and time



  • Database Replay and SQL Performance Analyzer in Real Application Testing allow you to analyze and test migration requirements before the move
  • The migration process is easier to plan through these preparation tools, reducing the time and resources required compared to PostgreSQL

Backup and Recovery


  • The data recovery process is straightforward, as it simply replaces directories and sub-directories plus the associated WAL files
  • PGdump and pgbasebackup are simple and straightforward database backup solutions



  • The data recovery processes can be overly complex
  • RMAN provides an efficient and straightforward database backup

Choosing a Database Management System

Overall, PostgreSQL and Oracle are evenly matched in their capabilities, performance, and compatibility. Oracle takes the lead on security, replication, and availability, while PostgreSQL has stronger API compatibility, cheaper support and more robust scalability. As database administrators, we think your choice of databases depends on your company’s priorities.

If you want an easy-to-use database you can customize for your operations, with a low Total Cost of Ownership, then PostgreSQL is a good choice. If high availability and flawless replication during voluminous transactions are the most important things for your business, then Oracle provides robust functionality.

Datavail offers many resources to help you decide between PostgreSQL and Oracle, from choosing the right database technology for your company to executing a migration. We deliver the DBA expertise, services and strategies to help you get the most out of your data and database technology.

Your database administration team manages and optimizes your databases through monitoring, maintenance, disaster recovery, user support, training, migration planning, and more. We offer flexible DBA capacity, so you get the right level of support throughout your technology journey, from one-time projects to 24/7 assistance.

See how Datavail can help you manage all your complex database needs and maximize your investment in PostgreSQL, Oracle and other database technologies.

The post PostgreSQL vs. Oracle: Let’s Compare appeared first on Datavail.