Performance complaints often start the same way: “The database was faster before migration.”
In many Oracle on Azure projects, the migration completes successfully, users can connect, and applications function normally. A few weeks later, however, complaints begin to appear. Reports take longer to run, batch jobs miss their windows, and application response times gradually increase.
The first instinct is usually to blame Azure infrastructure, but the root cause is often a combination of sizing, statistics, and memory configuration.
One issue I frequently encounter is sustained high CPU utilization. The VM may have sufficient resources on paper, but Oracle memory settings were carried over from the previous environment without considering the new server specifications. When CPU usage remains consistently high, I normally start by checking both the operating system and Oracle workload.
top
vmstat 5
From the Oracle side:
SELECT name, value
FROM v$parameter
WHERE name IN ('sga_target','pga_aggregate_target');
A surprisingly common finding is that the SGA and PGA settings were never reviewed after migration. Right-sizing these parameters for the available memory can often improve performance without any infrastructure changes.
Another issue appears when applications suddenly report slow queries after migration. The SQL statements may be unchanged, but execution plans look different. One of the first checks should be optimizer statistics.
EXEC DBMS_STATS.GATHER_DATABASE_STATS;
Many migrations involve significant data movement, schema changes, or platform changes. If optimizer statistics are stale, Oracle may choose inefficient execution plans even though the underlying SQL has not changed.
For larger Azure VMs, NUMA awareness is another area worth reviewing. Ignoring NUMA considerations can lead to unexpected performance behavior, particularly on systems with large memory footprints.
Memory-related issues can be even more disruptive. In severe cases, database processes may terminate unexpectedly due to operating system memory pressure. When investigating Out Of Memory (OOM) events, I typically start with HugePages configuration.
grep Huge /proc/meminfo
HugePages help Oracle manage large memory allocations more efficiently and reduce overhead associated with standard memory pages.
Another setting worth checking is swappiness.
cat /proc/sys/vm/swappiness
For Oracle database servers, a value of 1 is generally preferred to minimize unnecessary swapping.
sysctl -w vm.swappiness=1
One lesson I’ve learned is that performance tuning after migration should begin with validation rather than optimization. Many teams immediately start rewriting SQL, adding indexes, or purchasing larger VMs. In reality, the problem is often related to stale statistics, memory settings, or infrastructure choices made during deployment.
I also recommend avoiding burstable B-Series VMs for production Oracle workloads. They may appear attractive from a cost perspective, but sustained database workloads can quickly consume available CPU credits, leading to inconsistent performance.
Whenever a migration project completes, I perform a simple post-migration review covering four areas: CPU utilization, memory configuration, optimizer statistics, and storage performance. Most performance issues discovered during the first few weeks can be traced back to one of these categories.
Oracle databases generally perform very well on Azure when the environment is sized and configured correctly. The challenge is ensuring that migration activities do not stop at data movement alone. A successful migration should also include validation of memory settings, optimizer statistics, and operating system configuration. Doing so often prevents the performance complaints that appear after go-live and saves countless hours of troubleshooting later.
