Oracle Database Reviews

We primarily use the product to store textual data and support applications like our HR and case management systems.

The platform's security features and stability are commendable.

They could provide ease of migration and competitive pricing for the database.

We have been using Oracle Database since 2005.

I rate the product's stability a nine. We haven't encountered significant issues.

Around 500 users access Oracle Database regularly in our company. We haven't faced scalability issues; it's more than enough for our current needs. 

Once you're familiar with the product, setup becomes easier. Single-node setups are quick, but integrated configurations can take more time.

We get help from integrators to set up the database.

The platform is highly-priced. 

I rate the security features an eight or nine.

I would hesitate to recommend Oracle Database solely due to its high cost. If pricing were more competitive, I'd be more inclined to recommend it.

Overall, I rate the product a six out of ten.

It is our core for bank processes.

The scalability is very good, and it is stable.

The interface is not reliable because the GUI is old.

It needs to be more attractive.

It is very stable.

The scalability is very good.

We have about 120 users.

It was implemented by a vendor.

We have a yearly license.

For us as a bank, the price is not too high, but for a small business, it would be an expensive solution.

I would rate Oracle Database at nine on a scale from one to ten.

We use Oracle Database for running ERP systems and for managing clients.

What we like most about Oracle Database is its security, scalability, and ease of implementation. We also like the performance of the solution.

The cost of the license of Oracle Database is more expensive, so we have clients who chose to use a different solution, because of the cost. This is an area for improvement for Oracle Database. The usage and security are okay for Oracle Database, but its pricing is more expensive when compared to its competitors.

We've been dealing with Oracle Database for 15 years.

Oracle Database is a stable solution, and I never had any incidence of instability using it.

Oracle Database is scalable, e.g. if your company is growing well, you can easily reach the requirements of the company according to the number of users and performance when using the solution. 

The technical support for Oracle Database is perfect. Whenever we contact their support, it could take time to get feedback from them, or get the solution from them, but in the end, they're able to provide it.

Setting up Oracle Database was straightforward.

The license cost of Oracle Database is more expensive, and this could result in some clients moving away from it. When it comes to the licensing for the processor, it becomes more expensive, but it could become cheaper when you know how to use an ODA. When you're using other servers, the licensing becomes more expensive.

Additional charges could also come from Oracle technical support, but there is a lot of documentation on the website, and you can also get solutions from the Oracle Community as a workaround.

We are using Oracle Database and Oracle Storage, and those are the products we are mostly using. We are using the 12c version of Oracle Database, and it's on the cloud. The solution can be deployed both on cloud and on-premises.

Oracle is our partner, but not a full partner.

I would recommend Oracle Database, especially to financial institutions, e.g. entry-level or mid-level.

On a scale of one to ten, I'll give Oracle Database an eight.

The solution is primarily used for support servicing. The whole IT infrastructure uses Oracle. Oracle is a focal point. It's transactional processing as well as data warehousing.

The solution's most valuable aspect is its reliability. It just works. You never have to worry about it.

I've worked with the solution so well, I have a very strong understanding of it as a whole. I know everything about it. I'm very comfortable with it.

The solution can scale well.

The stability of the product is excellent.

Installing, configuring, and supporting an Oracle RAC system is a very complex task that requires special skills. A novice who has never done it before will struggle. Therefore, I think that in the future all Oracle RDBMS customers will gradually switch to cloud databases, preferably, to Oracle cloud.

It takes a significant amount of time after submitting an initial SR with Oracle Tech Support before your case reaches a technical expert with whom you can actually work on the issue resolution. Before that, you have to deal with people who are not experts.

Oracle RDBMS is expensive.

I've been working with Oracle since 1994. I have a long history with the solution.

The stability of the solution is excellent. The performance and reliability are great. There are no bugs or glitches. It doesn't crash or freeze. It's very good overall.

Oracle is very, very scalable. If a company needs to expand the solution, it can do so.

Our organization is quite large. There are hundreds of IT personnel using Oracle.

I've dealt with technical support in the past and I personally do not find them to be very good. 

Usually, it starts very slowly. Before you get to the right people, you go through the people who hardly understand the problem and they keep asking stupid questions. Then only after a couple of weeks, you finally get in touch with the person who really understands. It's at that moment that your work starts. However, before that, you have to go through the process of finding someone to answer your question. 

They need to make the process faster or hire people who understand the solution better.

Currently, our organization is moving away from Oracle. They're moving to Amazon AWS and they're considering several databases, as a potential alternative. This is due to the fact that Oracle is very expensive.

In truth, I'm not sure the company will ever be able to get rid of Oracle, as it would require rewriting everything. Currently, Oracle is the basis for everything. Just to switch to something else, they would have to rewrite everything. It will be a huge undertaking, and it would take several years.

The initial setup is not exactly straightforward. Real-life Oracle installation is very complex and a regular non-proficient person can hardly do that. I am not an Oracle DBA, however, many years ago I was an Oracle DBA. I don't have the certification. However, when I tried to install Oracle on a cluster of Linux machines to do some cleaning, it took me several weeks. I had to go through Oracle documentation, and I was trying and failing. Finally, I made it work, however, it was really difficult. Even for me, with so much knowledge of the system, Oracle installation is really difficult. Years from now, likely nobody will be doing it at all. Everybody will be using Oracle cloud instead.

We have quite a few people maintaining the solution, as we are a sizable organization.

It's best to have a professionally licensed individual assist in the implementation process.

The pricing is extremely high. It's one of the reasons our organization is looking for an alternative. They would like to move away from Oracle to lower their costs.

I'm a customer and end-user.

I would advise organizations considering Oracle to not do on-premises. The best way, nowadays, is just to pay money to Oracle and use Oracle-managed databases from the cloud. They don't require a data center for the hardware. Cloud computing, is what people should do instead.

I'd rate the solution at a ten out of ten. That said, I am aware that it is quite an expensive option for most organizations. Even our company, which is quite sizeable, finds the overhead costs high.

I support the backend and administration tasks for the databases in my organization, and for our clients, and Oracle is one of the products that I work with. The tasks I perform are things like creating the database and then maintaining it. I do not work with specific use cases but rather, provide support for them.

All of our databases are accessed remotely and are hosted on Linux servers. It is not always easy to manage, considering things like the firewalls that are in place, so we have our own scripts for this.

The cost needs to be reduced because right now, all of our customers are asking us about how they can migrate to any open-source database. This is a very common question and I have been checking our ability to migrate, as well as the tools that we have for doing so, to a product like PostgreSQL.

Oracle is an RDBMS, although most of our customers are now moving towards Big Data. There are open-source databases and you don't need a schema. You can store whatever you want. I would like Oracle to do more for Big Data in the future.

I have been using Oracle Database for more than 12 years.

Oracle is a stable product and we plan to continue implementing it.

This is a scalable solution.

We deal with many database products including Oracle, MySQL, PostgreSQL, and others.

The installation is straightforward. We have both on-premises and cloud-based deployments.

The amount of time required for deployment depends on whether it is a single instance. This time of installation may take 30 minutes. Our installation scripts make it easy to do.

We handle all of the administration tasks including implementation, installation, daily operation, as well as backup and recovery procedures.

In some cases, we have to provide high availability for our customers. Some of them may already have a cluster, so we would implement it. We also provide technical support to them.

We are a team of 10 database administrators.

This is an expensive product.

This is certainly a product that I recommend for large enterprises. However, for smaller companies, we can use an open-source database. That said, if you need something that is highly available and scalable then you have to choose Oracle Database.

I would rate this solution an eight out of ten.

So what happened is that today IT is facing a lot of challenges, because the data has grown so fast. They have to find a way to manage the cost, the performance, and the capacity. So that's why we have this strategy called information management: a strategy to manage this data within a reasonable cost.

Oracle 12C introduced these two new features, called ADO, Automatic Data Management, and Heat Map and combine together to implement information management in the database. We found that it is very useful to implement a tiered storage strategy. Today, we all know that SSD, (which) stands for Solid State Drives, really can help improve database performance by reducing a lot of storage IO bottlenecks. But it is not very cost-effective to put a large amount of non-active data into SSD because they  are not seriously impacting the performance, and also they tend to be in a large volume, and it can be very costly to put them in the SSD. That's why we introduced (the) tiered storage. 

The idea is we put (the) active data in the tier one storage and put (the) non-active data in the tier two or three storage. We want to use ADO and the Heat Map together, to implement this tiered storage strategy. We found that it's very useful, because these features allow the database administrator to write a policy, and then, this feature will automatically move the data around you don't have to physically copy it, and the feature will do this for you. Your only manual work is to write policies. We already implemented this in one of our tiered storage solutions. We have this one, with the PCI storage, as the tier one storage. We also have the tier two storage using the traditional spinning disk. We used this ADO and Heat Map features to manage the data around the tired storage, and it turned out to work very well.

So this is a very good tool, but I would like to add some more features. One thing I would think about is that, the database lets me write some new rules. Right now, the data moving is mainly based on how much this tier one storage is full. Like, if 80 percent of full? Then it starts moving the data. What I really want is, based on how much the data has been used. So it's possible to do that, but today, the database administrator has to manual write up the custom solution to check that. So I would like it to allow us to use plain English like, no modification in 30 days, and so instead of writing the complex PL/SQL procedure to do that this is already implemented in data compression. There is another feature for ADO that is to compress data, instead of moving data.

And it's not moving data. That condition is already implemented in the compression. But I would like to implement the same way in the data movement. Another thing is that right now, currently, when they check data, they only check data the last time the data was used, instead of frequency. So I want to have some way to go and say this data has not been used, has been used only one time, Even data was used yesterday I still want to move, but (according to today’s ADO implementation) even if they use it (data) one time, as long as in recently like yesterday, it is equal to 1000 times usage, (so the data will not be moved.) So I would like to have some way to do that (to tell the difference). 

Another feature is that this ADO, currently does not apply to multi tenant databases, which is a very important part of a database. I would like to implement that. by adding this feature, to support that (the multitenant database)

It's a very, very stable product. It's part of our 12C new features, I didn't see or feel a lot of issues, but I do recommend it because the data moving could serious impact to your database performance - so test it, before you move the production. So this comes to, not exactly how stable the product is, but how stable your rules are.
If you write the wrong rule, you move the active data to tier two storage, you will suffer your performance. And also, another thing is, when moving data, be careful because all DBAs know that, if you move data across the storage, potentially your index becomes invalidated. Then all your database query will go to the full table scan. Then you actually get a worse problem than ever.

So ADO, they tried their best to re-enable the indexes. But just be careful because in our experience, it's not 100 percent covered. So my advice is, check that. So after they move, use single query to check the index's status. If you found some index not valid, rebuild it (with) another single command, you can do that. That will ensure that you only get a good part of it, not the issue.

So the scalability has something to do with how much data you move around, so that's why you need actually scale. You need to have some idea about how much data (to move). You want to schedule a good time window, so that off your peak time, so you can you do data moving. The DBA is the one who knows this most, you need to plan ahead and test it ahead.

I would rate it, eight to nine. Because, one of the areas for improvement, for me to write a PL/SQL procedure, that can be implemented for the product. They already have this for compression. Why didn't they implement in the data movement? The writing procedure was not easy to write, yes. I would like to have that, yeah.

The most valuable feature is how evolved the solution is right now. It's been around for a while, and I think it's been servicing a lot of different use cases. I think it's really stabilized, evolved, and you can actually put it to use in multiple scenarios. It adapts itself just as well to most business use cases.

I think the best part about Oracle is it keeps evolving. It's not adding any more features to it. There's a big move toward custom cloud services - big databases in the cloud - and obviously there are people with apprehensions in terms of what will happen if that data is shared. They are working towards addressing that issue. They are kind of compartmentalized, and kind of made some of the domains private, to maintain the security for certain critical domains. You still have the power of using the cloud. That's the great thing about it: It keeps evolving. It doesn't stay still. It's very compelling.

It also provides reliability, in terms of handling large volumes of data. I don't believe there's another database server that people would pick. Given a choice, everybody would like to go with Oracle.

I think those are the two big features that really stick out.

It has definitely improved the way my organization functions. It's our database management tool. We have a lot of sensitive information. Different business verticals have a lot of sensitive information that they want to reliably preserve somewhere, and also be able to call back upon in a very secure manner. Oracle does just that.

At the same time, it has a lot of the algorithms where it tries to optimize itself in terms of how fast you can get the data out, and also how fast you can write to it as well. I think it's definitely improved and provides benefits to the industry; not just for the gaming industry that I'm part of, but generally for all verticals in the business world. As I’ve mentioned, it’s the database of choice for most business verticals.

I’d like to see them include a certain amount of intuitiveness in the optimization of the queries, and the algorithms for that could be better. There's still room for improvement in those areas.

One of the things that is also mentioned about Oracle is that with the RAC architecture, the storage is shared, and that sometimes becomes contentional. It's not so much the processing on the nodes; it's the data processing that becomes a point of contention sometimes – if they could do something so we can customize the RAC in some way, and also implement sharing, something along the lines of what Perl OOP has, where the storage is also exclusive to the nodes. I'm sure something like that can be brought in. Having mentioned that, I'm pretty sure they're already researching into it. That's something from my experience that can be improved.

I don't think you would pick another database for stability; for financial data, or anything related to money transactions, where you want to reliably store data, and you don't want to lose any data. You don't want to try to save something in the database and then go in the next day and not have it, obviously. Oracle is right up there in terms of stability.

Obviously, the scalability factor was increased with the Oracle Real Application Clusters (RACs). You have multiple instances of Oracle, with the shared storage, so you can spawn multiple processes to do large volume data lifting. You don't want to rely on one instance alone. You don't want to load that one node alone. It can do everything. You can spread it across nodes. The RAC solution gives you that.

In terms of the data scalability itself, if you don't want a shared storage, you have solutions such as Exadata. It provides very good storage and gives you great performance.

In all respects, Oracle on all fronts is doing great, including scalability. I don't see any issues with it right now. As I’ve mentioned, the great thing about the product is that it keeps evolving and tries to improve.

I think it's great to have those features.

Technical support is a little sketchy. It depends on who you get on any particular day. Oracle is a worldwide organization, so I guess there are certain sections that are not really well covered, in terms of building up a knowledgebase, and trying to go back and see how a problem was solved in the past, which should be an easy thing to do.

I think sometimes it comes down to doing that: going back, looking at the issue you are reporting, determining whether you've faced it before, and what the solution was. If there isn't a solution and if this issue hasn't been reported earlier, then be intuitive about it. That part was missing in the few instances where I've had the opportunity to call support.

As I’ve mentioned, it’s a worldwide organization. They're available around the clock, covering different time zones. All those aspects are covered. I think a little more intuitiveness in the solutioning for the support issues would go a long way in improving the experience.

We previously used plenty of solutions. Oracle was an easy choice. If cost is not a constraint, I would recommend Oracle ten times out of ten.

Setup is never straightforward. It's a pretty complex piece. I have actually overseen it, but it's mainly the database administrators, the DBAs, who actually worked on it. They do come back and work closely with us architects and engineers, in terms of how to best configure the infrastructure.

I wouldn't say that it is straightforward, but at the same time, it's been done so many times, there are so many use cases to fall back on. I'm pretty sure that if you get stuck somewhere, you will get the knowledge base, go back and get past that issue that you're facing at that moment.

It's all down to being so evolved. Oracle has been around for a while, so you have those benefits.

We moved from another solution, knowing the history of Oracle. We earlier conceptualized to be on Informix. Informix was one of the options we really considered. There wasn't much of innovation happening in Informix. It was more legacy. I think that is a reason why we moved to another database system that is more active with more innovation covering different aspects: scalability, data volume management and those kinds of things. At that point, Informix was definitely the only other option. Subsequently, we looked at other solutions such as MySQL for cost purposes, but having explored each of those, they don't really match up with Oracle for me; the scalability, the data volume management, those features, along with the reliability. There's a lot of hand-holding support that needs to go into those products to be able to match what Oracle offers.

In terms of data security and reliability, if that is of paramount importance, I would definitely suggest Oracle. If cost becomes a factor, in terms of the licensing models I’ve mentioned, then probably I would recommend a cheaper solution - maybe even open source - but that comes with a tradeoff of the data not being reliable.

For financial institutions, financial organizations, you would not want to put your data at risk. I think it's tradeoff with those aspects when making your choice.

The most important criteria when I’m looking at a vendor such as Oracle are the support and licensing. I look at the licensing model, in terms of whether there are certain things that they can do to support a company like ours, who've been engaging with them for so long. We have different business models. If they can offer some licensing options that would be more attractive to meet those business models, maybe offer some innovative solutions, that's something that I would look for.

In terms of the support aspects I’ve already mentioned, there are specific business use cases we're trying to solve, and not just rely on the knowledge base that's already accumulated.

Those are some of the things I look for.

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.