Oracle Database Reviews

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.

The most valuable features for us are the cloud-like traits of ODB, grid computing with version 11g onward, live database, and Data Guard.

We're a non-profit with branches all over the world -- Africa, India, and the US -- so we need a database solution that can be centralized. We have an entire datacenter in India, but our users need access to it from our other locations.

The key thing we need is a database that can pretty much run virtually in the cloud, that is, with a virtual datacenter. When we decided on Oracle three years ago, OBD was the only database that was cloud-like, scalable, and more robust than other solutions available at the time.

Honestly, it's not really in the cloud as such, but the definition of "cloud" changes daily. It's more on VMs, but the VM's are so powerful that we can access the database from anywhere without investments in machines or other hardware. We've been doing this since 2010 and we haven't hosted with cloud providers like Datamark or AWS, so we essentially have our own cloud.

While Oracle has been excellent, they haven't been growing or leaping forward like other vendors. I heard that Microsoft SQL Server will begin working with Linux. If that happens, Oracle has to do something because the cost will be one-tenth that of Oracle.

We haven't had any issues with the deployment of ODB.

The stability is good as the product has matured over the past few years. We initially implemented in 2014 and had upgrades since. We had some issues, which we told Oracle about and which they fixed. We had integration with a backend database because we are an Oracle workshop when it comes to database. They did not have too many customers using Oracle as a backend database.

We haven't scaled because of the unique constraints of our customized datacenter, but we use Linux because of Windows limitations. But we have been able to go from a mom-and-pop garage shop to where we are now.

The support is amazing. We have a great relationship with the non-profit technical support as well as with our sales rep with whom we've been with for ten years.

We have used Microsoft SQL Server, but the problem with that is that runs only on Windows. We wanted it on other units. Then we used Sybase, but that is more of a financial database, and didn't help much for our non-profit business. Then we used IBM DB2. That's a nice database, but IBM was considerably more of a hardware than a software part.

We wanted someone who is a player only in the database world because we had everything else and because we are non-profit, we do have tie-up with different companies where we get a different special rate for licensing.

We prefer Oracle because they are the niche players in the database world. We are pretty happy.

Because I'm a technical person and I have experience as a database administrator, the initial setup was pretty simple for me. The support was amazing and we didn't have huge roadblocks. If anything happened, such as issues with plugins, Oracle just gave us a patch.

Our implementation was done in-house by me and my team.

Because we're a non-profit, we have a buffet deal. For the first three years, they won't charge us any license fees for any use. It's all-we-can-eat. After three years, they'll come back and look at the footprint and license us based on that. This is a big deal for non-profits, but Oracle is willing to do it.

We looked at others who specialize in the cloud, such as CloudData. But Oracle is penetrating the cloud field. If you look at the Magic Quadrant, Oracle is positioned well with its RDBMS and Exadata, along with EMC Greenplum, Microsoft Azure, IBM's cloud solution, and others. We did PoCs with them all.

Its reliability and security are the features most valuable for us. We know we can depend on it and that it keep our data secure.

It's also a ubiquitous solution. It seems that OBD is everywhere. I know that knowing how to use it in one company will help me in my career at another company.

The biggest improvement to our organization is from a security perspective. It just keeps all our data safe as an integral part of the company. It's our go-to database solution.

Although we're not using the latest version, there are some ODB tools that are quite cumbersome to use. For example, we often use the standard backup tool and have found it to be pretty cryptic. It's needs improvement in usability as it takes a lot of effort to use.

We've been using it since 1992.

We've had no issues with deployment.

It's stable. We haven't had any issues with instability.

We don't. I know it does, but we don't. We are a pretty small shop. Our data's small, so not really.

This is one of our favorite things about ODB. The support is pretty good.

I used another database and data storage system as a developer in a prior role.

It's a very complex product, and it takes a lot of skill and experience to implement it. It's a lot easier now, but back then it was like 75 floppy disks for setup.

Consider an open source solution as well.

The key and most valuable feature of any database solution is its stability. In our experience, Oracle Database is highly stable, which is the best part of it. It's certainly much more stable than Microsoft SQL Server.

The biggest improvement to our organization is that with ODB's stability, it gives us back our time and attention to deal with more pressing issues. We know that we have ready access to our data with ODB, and that it can be relied on.

Although ODB is stable and reliable, to make stable and reliable it has to be carefully planned because it's complicated. You really have to know how Oracle works in order to not make mistakes that compromises the DB's functioning. You have to know what you're doing and you should make sure your entire team is familiar with the documentation.

We've had no issues deploying it. Again, you have to be careful, though, because it's complicated.

Stability is a 5 out of 5. Again, ODB's stability is its best and most important feature for us.

Scalability is a 5 out of 5. We've been able to scale it for our needs.

Technical support isn't perfect. I give them a 4 out of 5.

I found setup to be complicated depending on how it's to be used. For us, it was complicated but we knew what we were doing.

There's a lot more to Oracle, and it's not as simple as you think. It's not like anybody can go and install it because you need to know what you're doing. As a team, you have to go through all the proper documentation.

The most valuable feature for us is certainly the scalability of the DB as we need capabilities for multiple terabytes of data.

I don't know much about other organizations, and I've used SQL in the past at other companies, but because most of our customers are different federal government agencies, it's provided us scale to support many terabytes of data.

Recently with the 12.102 version, Oracle decreased the number of hardware you can use. I would like them to revert that back to where it was. We use the standard edition, so obviously that's going to hurt our customers as Oracle is reducing the hardware we can use.

We've been using DB since the beginning, so 33 years now. I haven't used it personally since then, but the company has.

We've had no issues with deployment.

It's definitely stable. We've had no issues with instability.

It's very scalable, which is the primary reason we use it.

Oracle's technical support is better than most, but it's not perfect. Obviously, when we open a ticket for support, it needs to get escalated a couple of times before we actually get an engineer who can really get down and help us. That's typical of the industry, so it's better than most, but not perfect.

The complexity of the initial setup depends. The patch releases have been simple: you download, you install, and it works fine. There have been no issues that we've run into there. The major upgrades, however, I think with the new 12.102, they've made some changes in it, so we're still trying to figure that one out.

It's a great product, no doubt about it. Oracle did a good job on it and that's why they have a big market share. I think if you're starting from scratch, look for other alternatives. Investigate the alternatives to see if they can meet your needs.

Technically, it's almost flawless, I would say. There are bugs in it of course, but they are bugs that doesn't impact us as a company.