Oracle Database Reviews

The best thing about Oracle Database is that it performs well when measured on any scale. As a Database developer, I think it offers the best development tools of any database solution.

Its cross-platform compatibility provides flexibility for different platforms like Windows, Linux, Solaris, HP-UX, and AIX. Oracle offers high-performance handling of XML data.

We are currently using Oracle 11g, where as Oracle 12c now has all the major features for easy development. However, as the database industry is growing, there is room to enhance object reusability by introducing some development framework or out-of-the-box concepts.

I've used it for 12 years.

There were no issues with the deployment.

We had no issues with the stability.

It is scalable. Indeed, you don’t have to worry about scalability as this is Database's strength -- it grows with your business and is an all-in-one solution.

I have had some discussions with a few DBAs. Oracle technical support is not very good compared to Microsoft technical support, the latter of which is more proactive and reachable. Secondly, Oracle technical support is more costly than its competitors.

I also have worked as a developer on Microsoft Dynamics AX with SQL server. The main reason we changed was because of the AX Dynamics cost - initial cost, customization, and maintenance. It is much lower than Oracle Database.

As with any vendor resource, availability is also a major issue for Oracle. As there is a lot of development flavors for Microsoft, resources are easily available and it's more flexible to work with on different technology. In comparison, Oracle resources are scarce and are mostly away from new market trends.

The complexity of the initial setup depends, as it is a self-manageable database for small databases, whereas for mid and enterprise levels, it needs serious attention.

The cost of Oracle Database is a little higher than competitor products, but it gives good ROI in the longer run.

For long term investment, it is the best option. Initially, its cost is higher, but its running cost is less than other competitors.

This is the best database product on the market.

There are several valuable features that we've found in our experience, including ACID compliance, strong backup and recovery features, smart cost optimizer, very good stability, performance, and it includes disaster recovery solutions.

The company I'm currently working for is an ISV that develops applications for the healthcare system, where High Availability is the main concern. Oracle puts the database layer at the highest level of reliability. As a plus, the smart optimizer can compensate for a poorly written SQL, giving good response times.

The biggest improvements are mainly high license costs and the unavailability of Enterprise edition options on the Standard edition. For example, on the Standard edition, you cannot buy transparent data encryption, needing the Enterprise edition to access that option (which has to be paid for separately). Official certification for VMware environments would also be an improvement.

I've used it since 2001, mainly on OLTP systems, as it is well-suited as an OLAP solution.

We have had no issues with the deployment.

All software has bugs and Oracle database is no exception. Oracle's RDBMS offers a high level of stability, but the increasing complexity (added functionalities and options) is in some way increasing the risk of hitting a bug.

We have had no issues scaling it for our needs.

The level of technical support is quite low compared to the software level. It's hard to find a skilled specialist and response times are high. On the other side, except for really heavy load systems, it's quite rare to have to engage support.

The Oracle setup process has been simplified over the years, but it's still a complex task, at least when it comes to High Availability/disaster recovery solutions (RAC, DataGuard).

I was an Oracle on-site consultant so it is one of my major responsibilities to set up the Oracle Database according to best practices. Always start from RPO/RTO constraints to design the solution and read the Oracle manuals -- they’re wide but very well written.

I would advise that you carefully evaluate the compatibility of the software solution with Oracle Standard Editions which are way less expensive. Also, take a look to the new Standard Edition licensing model (called Standard Edition 2).

I'm currently studying PostgreSQL, which is an interesting RDBMS solution and it's open source (similar to BSD license).

From a technical perspective, it is the best RDBMS solution on the market so far. For mission critical solutions, I suggest engaging a senior Oracle database consultant to do the job. An experienced DBA can configure the system to leverage the full potential of the RDBMS both on the performance side and on the availability (backups, BC, DR).

The flash drive recovery feature is the most valuable aspect of ODB for us. There have been many instances when a user mistakenly deletes important files from their flash drive and ODB has been able to recover that data.

The biggest area of improvement that I can suggest is with the stability. I've been using ODB for a while now, and there are have been occasional instances of bugs, glitches, and hiccups. It's never anything major, but they have been annoying. Yes, it's improved over time, but there always seems to be something that has to be fixed.

We haven't had any issues with deployment.

It hasn't been 100% stable, but I think over time it has become more stable than previously.

It has scalability. We haven't had any issues with being unable to scale it.

In our experience, the level of technical support has been in the middle. There are times when they're really good, and there are times when we've had to solve issues ourselves.

We didn't use a previous solution. It's always been our database product.

Although I don't do setups anymore myself, I found it very easy and straightforward.

We didn't look at other options. It was the first database solution we used.

It has evolved pretty well generally. There are consistently new features and Oracle is making ODB more useful.

Its big advantage is from a market perspective. Over 70% of the market uses Oracle Database. It's the market leader in the mid-tier for relational databases, probably, I think, tied with IBM right now.

The support level is good and well-documented. I can go to the web and I can Google just about any problem I have.

And another reason we use Oracle is that it's going to stay in business for a long time. So it's worth investing in training in the software long-term for us as opposed to, say a, smaller open source product that comes and goes.

It's very easy to get training and resources. Because we use a Linux operating system, our preference is for Oracle. It has a full suite of products and they all play nicely with each other. So if I get something from Oracle, I'm pretty sure it's going to work on my Oracle Database.

I'd like them to expand their support for Oracle Spatial and Graph, an app for Oracle Database. It only supports a single node right now. And really, to be practical, you want something with multiple nodes.

Also, while Oracle does have a NoSQL database (called Oracle NoSQL, a version of Berkley NoSQL, which isn't widely used as far as I can tell), I'd like to have the ability to do a heterogeneous join between my Oracle Relational Database and my NoSQL database, and I'd like to be able to use SQL on my NoSQL.

I've been using it since the 1980s. We use it alongside the Fusion suite, some of the big products there. We use ADF, which is the Java framework that they provide. And we make extensive use of PL/SQL-based products. Traditionally, we used a lot of Forms, but that's being phased out. Now we're using a lot of APEX.

It's pretty easy to install and deploy.

It's very stable. It's a well-known product and, while it does have problems, they're all well-documented. There are traditional security patches and, sometimes, some problems with new functionality. As long as you apply your patches regularly, they're resolved. And Oracle Support Group does resolve them.

We've had no issues with scalability.

The level of technical support is good, but you can put in a TAR and sometimes it will just disappear in space. The challenge for the support often is that if you don't use a straight Oracle configuration, in particular if you use a virtual server, they won't won't guarantee the support because they can't support every possible configuration. However, it doesn't mean that if you have a problem, they won't try to answer it.

It's pretty easy to install. The installation process has improved remarkably since the 80's when I started working with it. It wasn't friendly then, but it's very easy for me now. You just push a couple buttons and move through. If you know what you're doing, you can do it with defaults set up on a basic Oracle Database.

Now if you want to do something a little more complex, like Grid or clustering, you need to take some specialized training.

I implemented it myself.

You're always going to find some product that's cheaper. Oracle is never cheap. You're always going to find some product that is, in certain configurations, faster.

Especially for government organizations, it would always be my first pick.

The most valuable feature is the TDE advanced security as there are several options of different encryption algorithms. It's also easy to implement Tablespace Encryption.

We're able to go through and encrypt our database much faster using Tablespace Encryption versus using column encryption which requires you to identify each atomic piece of information to be encrypted. This ease-of-implementation gives us cost savings as we're able to get things done quickly.

I've heard rumors of an upcoming ability to get rid of ghost data. Here's an example: if I have a column in a database, say social security number, and a policy comes up and says encrypt social security number, and if there's an index on that column before you encrypt it, if you look at it, you can see the information in plain text. When you encrypt it, it does not encrypt the index. What it does is it marks the blocks available and creates a new index. Now you have ghost data -- plain text data.

We need an ability to shred that ghost data. Right now what I do is I advise people that when they encrypt something, manually move everything out of the old table space and then shred those data files. To be able to get rid of ghost data automatically would be great.

We've had no issues with deployment.

It's incredibly stable. There's a couple things you do need to be aware of, but it's not so much the stability issues, it's actually the data leakage issues. Because we're talking about encryption here, you have to be careful that data can leak out in third text, and I'll give you an example. If you take a data pump export of encrypted data and you do not specify encrypted in the command line, it will be saved in clear text. That's one issue.

Another issue is if you gather histogram information on encrypted data, that data will be stored in the statistics tables unencrypted so you have to use a product such as Database Vault to wall that off so you can protect it.

I don't think there's an issue with scalability. Most people are more concerned about performance because you have to encrypt and decrypt on the fly, but with hardware encryption modules that is really a null issue. There is very little performance impact. We've encrypted data out to 25 terabytes in one system and we had no performance issues.

I haven't had to contact technical support.

I was involved in the initial architecting setup of this. It's not difficult, but it's very precise. Simply, the easiest thing to think about is you have to store your encryption keys. If you lose your encryption key, you've lost your data. One of the first things you do once you've encrypted your data is back up your encryption keys. Actually, you want to back up your encryption keys before you start encrypting the data. We generally burn those off onto a DVD and store them in the safe and then we store them on another system offsite. That is the one thing that will really burn you if you're not careful.

It's not time-consuming at all. The encryption keys are minuscule. I have Word documents that are bigger than the encryption keys. It's just if you lose that encryption key, you're hosed.

We looked at SAN encryption, but we wanted a system that was native to Oracle so that we're not worried about whether everything is integrated properly.

If it's not implemented correctly, you can still have leakages of clear text data. Understand the product and it's limitations before you implement it. Understand where things can leak and plug those holes ahead of time.

You also want to be able to basically understand the product end to end because here's another little issue: if I encrypt the table space at AES 126 or AES 128 and a policy comes out, we're now going to encrypt everything AES 256, you cannot re-encrypt the table space. You would have to create another table space, encrypt it at AES 256 and then move that data over. Then you have the issue again where you can go back and shred the data.

It's pretty impressive how much data we can manage and how fast we can do it with Oracle DB. The performance is also valuable, especially when compared to MySQL or DB2.

We handle vast amounts of data and we need to access it quickly. Oracle DB allows us to be able to do that. Again, that's impressive to us.

I don't like the user interface. I prefer to work with a console and proper lines, which, for me, is the easier way to operate Oracle DB. The current way that things are done is much more tortuous.

We haven't had any issues with deployment.

Oracle DB has been very stable for us, especially since it has provides us with backups. But it needs people to manage it, so you have to pay attention to properly staffing it once implemented.

It's very scalable and, in fact, scales beautifully. All we've had to do is create more than one instance, which is very easy to do.

I had an ORA-0600 error which initially didn't "exist" because it wasn't mapping with technical support. It took them some time to resolve the issue.

The initial setup was easy and straightforward. It required only a few clicks.

We implemented it ourselves at it was so easy to do.

I think it's the best database technology on the market. I recommend it to anyone considering it.

In our business, we deal with vast amounts of financial data. We need to be able to capture all of it accurately without any downtime. We're able to do that with ODB because it gives us 99% uptime while reliably capturing all the data that's important to our business.

The look and feel of it needs improvement. It looks and feels the same throughout, but there are times when we want or need a different instance to have a different look and feel. In other words, it would be nice to be able to customize it to better suit our needs.

We've had no issues with deployment.

It's very good, very stable. We're in our own ODB shop, and so far we haven't seen any issues with instability.

It is very good, very stable. We are in our own Database shop, and so far we haven't seen any issues.

We can scale it, and we are currently exploring cloud options.

We are always in touch with Oracle support, so we create cases with them often. They are very good and very consistent across all our Oracle products at every location. Technical support is centralized so we know we'll get good, consistent service from the reps.

It's very easy and straightforward to set up.

We implemented it in-house because it was so easy.

We are actually exploring other products like GoldenGate. We believe this product will give us our next big break. We're also looking into Cloud Control 13c.

As we're already Oracle customers, we're upgrading from version 11g to 12c. The most valuable component of the new version 12c is the additional processing power it provides.

For what we primarily do, we do heavy processing of OLTP and OLAP. We've used DB for some additional success in that regard.

The middleware, particularly Oracle Fusion, is what concerns us most and what we think needs the most improving.

We've had no issues with deploying it.

There have been various stability issues so far, but the main concern, again, is the middleware. We're looking for some improvements in those areas.

We've had no issues scaling it for our needs.

We use technical support all the time. Whenever we run into any issues, we open up Oracle SRs. We get responses and we integrate them into our system, and we generally close out the issues successfully.

I've been involved in all of our major upgrades and it's never straightforward. There are always complications because of the complexity of it all.

You probably need to consider some onsite support as much as possible because I'm not sure if the SR process is the best way to go. You probably need some expertise right there onsite that's familiar with your specific firm or agency. It's always difficult if you're just doing SRs.