Re: PostgreSQL

Expanding on Kellyn's last point, specifically about trying to cram 50 kg of Oracle database onto 5 kg of infrastructure...

In each of the source Oracle databases, have you measured...

• I/O latency o a good indication is the average wait time on "db file sequential read" events from AWR/STATSPACK reports
• I/O throughput o IOStats By Function and IOStats by FileType are two sections of the AWR/STATSPACK reports to reference

Most importantly, are you generating AWR/STATSPACK reports from "peak workload" periods of time?  Or are you just using any old snapshots from any old time period?  If the latter, then don't bother.  As with any use of AWR/STATSPACK reports, the time period captured is the whole point of the exercise.  When one is assessing workloads to move to new infrastructure, it is best to assess the worst-case scenario, which are peak workloads.  If you don't know when peak workloads occur in your database, one bit of help might be the "busiest_awr.sql" script posted on Github HERE
<https://github.com/Azure/Oracle-Workloads-for-Azure/blob/main/az-oracle-sizing/busiest_awr.sql>. It queries the DBA_HIST_SYSMETRIC_HISTORY views to display AWR snapshots with the highest values for CPU and I/O.  I don't yet have a version of the script for STATSPACK, but I expect to have one posted by the end of next week, if not sooner.  Since STATSPACK doesn't capture SYSMETRIC information, I anticipate having to use SYSSTAT information, which I believe is less useful and has more problems for this sort of analysis.

Anyway, if an AWR/STATSPACK report generated under peak workload indicates an Oracle database with the following characteristics...

• 73 average active sessions (AAS) for significant periods of time
• I/O latency averaging 0.3 ms
• I/O throughput averaging greater than 3000 MB/s

...and the plan is to replatform it into a PaaS service or infrastructure capped at 300 MB/s, then it is a non-starter.  Same if the PaaS service or infrastructure has a maximum of 64 vCPUs.

Of course, my own self from 10-15 years ago would have stepped in now and pontificated about how any Oracle workload can be tuned to run on an iPhone, but the reality is that it is unlikely.  I still know that there is always room for improvement, but also that not many organizations are interested in optimizing.  The dreaded phrases "/it is what it is/" and "/if it ain't broke don't fix it/" come into play.

This platform-agnostic baseline information is so easy to obtain, and it provides immediate value when assessing rehosting or replatforming.

On 1/6/2023 7:33 AM, Kellyn Pot'Vin-Gorman wrote:
> I'm going to jump in here and start with the reason why-  Although Tim
> and I both do Oracle on Azure IaaS, we receive a lot of Oracle
> databases that fail migrating to PostgreSQL.  The reasons that this
> commonly happens is as follows:
> 1.  The team underestimated all the applications and connectors post
> the database migration that required refactoring.  Oracle is never
> just a database-  there's always more to consider.
> 2.  The database housed complex PL/SQL functions and advanced Oracle
> features that weren't able, (and remember, I'm not the one who did the
> migration, just received the database back and hearing this second
> hand) to duplicate it with PostgreSQL.
> 3.  The performance had years to be optimized in Oracle and
> refactoring takes considerable time and dedication.  If the customer
> and the team performing the migration isn't willing to not just
> refactor but dedicate a full redesign to use the best of PostgreSQL to
> optimize the workload, that workload "explosion" can impact
> performance so significantly that it's unacceptable.
> 4.  The flavor of PostgreSQL MATTERS.  What EnterpriseDB Big Animal
> can handle is different than CosmosDB Hyperscale Citus and that's
> different than Amazon Redshift or what Yugabyte offers.  Use the right
> PostgreSQL for the job.  If I see one more 3000 MBPs Oracle workload
> attempted in a PaaS PostgreSQL that can only do 300MBPs max, I'm going
> to scream. :)
>
>
> *Kellyn Gorman*
> DBAKevlar Blog <http://dbakevlar.com>
> about.me/dbakevlar <http://about.me/dbakevlar>
>
>
>
> On Fri, Jan 6, 2023 at 4:37 AM Terrian Thomas J CTR DLA INFO
> OPERATIONS <dmarc-noreply_at_freelists.org> wrote:
>
> Here are some open ended question for the group…We are starting to
> look at migrating our databases from Oracle to PostgreSQL.  I know
> nothing about PostgreSQL.
>
> Has anyone done a pro’s and con’s list of Oracle vs. PostgreSQL?
>
> Anyone have a lesson’s learned list from migrating from Oracle to
> PostgreSQL?
>
> Any thoughts/comments on PostgreSQL?
>
> I kind of think that you get what you pay for…wouldn’t that mean
> that Oracle would outperform PostgreSQL in every way?
>
> Any comments would be appreciated.
>
> Tom
>

--
http://www.freelists.org/webpage/oracle-l