ROLLBACK and COMMIT have the same semantic meaning in both systems also SAVEPOINTS mean the same. Every piece of code doing some DML that is not to be committed immediately must start a transaction with a BEGIN statement. While the first statement after a COMMIT starts a new multi-statement transaction in Oracle RDBMS, Postgres operates in autocommit mode. Anticipating different degrees of load activity at any one point in time between the competing SQL workloads makes tuning shared buffers much harder and perhaps impossible to tune for both at the same time without adding significantly more reserved memory to shared_buffers even though it may not need it all most of the time. In that case you have to make sure you have enough OS memory and shared_buffers memory to handle the surge when multiple SQL workloads compete for the same paging resources. But when multiple, separate SQL Workloads are at work within a single PostgreSQL instance with their own set of tables, you may begin to see contention for memory-resident pages between the separate SQL workloads. So you usually get your 95% to 99% cache hit ratio. Normally with a single application, one thing good about it is that a lot of the disk to memory activity is with the same heavily used tables. With multiple, separate, heavy-hitting, DML applications hitting the same PostgreSQL instance, we start to see inherent problems when unrelated SQL workloads (separate databases, schemas, and tables) compete for the same memory resources.
This would be expected with multiple, heavy-hitting applications working against the same PostgreSQL Instance. A general rule in PostgreSQL is that as the number of active, concurrent transactions (pg_stat_activity.state = 'active') exceeds 2 times the number of CPUs, we begin to experience CPU load saturation. The next two sections illustrate CPU and Memory factors that come into play with PostgreSQL being a host to 2 or more heavy-hitting applications.Ī PostgreSQL instance that has multiple heavy-hitting, DML applications connected to it can have CPU load problems due to the fact that we are stacking up or accumulating the concurrent, active transactions of multiple applications. So, the "right" solution without some re-architecture and/or use of 3rd party tools and extensions is to migrate the applications off of Oracle RAC one at a time to separate PostgreSQL instances, one heavy-hitting application per PostgreSQL Instance. While Oracle RAC can divvy up the applications and load balance them across the Nodes in the cluster, there is no such thing in PostgreSQL. The big picture that is missed here is ACTIVE-ACTIVE (Oracle RAC) and ACTIVE-PASSIVE (PG). A common mistake with migrations from Oracle RAC farms is to associate all of the farm applications with one PostgreSQL Instance. With RAC you may have multiple, separate, heavy-hitting, DML applications usually of the OLTP type connected to the same RAC Cluster, where RAC serves as a type of application farm. Oracle Enterprise has a more direct migration to PostgreSQL than does Oracle Real Application Clusters (RAC) in some cases. Postgres 8.4, and sometimes this also works for earlier versions.Oracle 12c is in some aspects different (Multitenent DB) but migration may be even easier.Oracle 10g to 11g (most stuff will work down to 8i).If you're porting Oracle SQL to Postgres SQL for theĪCS/pg, you should also be quite familiar with AOLserver Tcl, especially the AOLserver database APIs. Knowing the details of Oracle SQL and Postgres SQL are obviously tremendous advantages, but the hints in this document should quickly bring you up to speed on what the differences are. 2 Oracle Enterprise and RAC Considerations.
0 kommentar(er)
