Oracle is a great database. It is cutting edge and it has a huge team of developers behind it as well as massive funding.
There are not any areas where it lacks anything major that exists in other comparable databases.
The problem with Oracle is both that it is expensive in the first place, but also that all of the extras are chargeable and also expensive!
Continue reading “Can you improve your Oracle database using Postgres?”
Oracle is the database to beat in terms performance and features or at least is positioned that way. More importantly, if you are thinking of migrating from Oracle to Postgres to save money, you need to know that your new database has at least the same features at the one that you are moving from.
Continue reading “High Availability Options in Oracle vs Postgres”
High availability is one of the most important concepts and features for a database system. For most enterprise level applications, downtime has a direct financial cost and the actual loss of some or all of your data would be catastrophic.
You need to know that the system that you are moving to can protect your data as well as the system that you are on at the moment.
The Oracle database has been the gold standard for enterprise applications for a long time now. It has great performance, solid reliability and most of the features that you could want are available. The big problem is that it is expensive. And I mean REALLY expensive. That’s just for the base product as well. All of the extra features that you might want are chargeable extras which means that wench developing for Oracle, you often have to work without some of the more advanced features because they would cost too much.
Continue reading “Should you migrate to Postgres from Oracle?”
Oracle services were a feature introduced in Oracle 10g. Their function is to simplify workload management by allowing you to group applications that share traits such as thresholds, priorities and attributes.
The Oracle database is presented as a service and so you always have at least one service running. It is good practice to create at least one more service for application workloads and not to use the default Oracle service as it cannot by changed and will always allow connections.
One instance of a RAC database can support multiplke services and one service can spoan multiple instances. One service can support many applications, one or even a subset of one appliation.
You can create a service to accommodate batch users and another to deal with online users. Alternatively, you could assign a service to handle a particular application, application type or parts of an application etc.
It is recommended that you use a service to connect applications to the database and you do this by specifying the service name in the application’s connection string.
The resource manager is tightly integrated with services and you can control how and when services can run in an instance with it. It also allows scheduler jobs to tun as a service which allows you greater flexibility about how and when they run.
Oracle ASM keeps redundancy quite simple by providing only 3 options. you can choose to have no redundancy or mirroring provided by the ASM instance. This is the ‘External’ option and assumes that you are handling mirroring somewhere else perhaps through hardware raid on your storage network.
You can chose ‘normal’ 2 way mirroring r ‘High’ for 3 way mirroring.
This option is set for each disk group and can be different for every one.
Basically, the redundancy level determines how many disks you can afford to have fail before the disk group is dismounted or data loss occurs. With external mirroring, you can’t afford to lose any disks whereas with 3 way mirroring, you could lose 2 disks and there would still be one copy available.
With normal RAID, the level of mirroring is set for the disk (or disk group). ASM gives you a more granular level of control. For example, it is possible to set different mirroring levels for different files on a single disk group.
When data is created or an extent is allocated, ASM creates a primary copy and a mirrored copy. these copies are distributed across failure groups so that losing a failure group completely would not in and of itself cause the loss of any data.
You cannot change the redundancy levels of a disk group once it is created. If failure groups are not specified, ASM places each disk into its own failure group (unless the disk group contains Exadata cells.