Oracle Database Reviews

Of course, it has been around forever, so the scalability of Database is, in my experience, the most valuable feature. The fact that there's so many applications written for it is great. We've seen others who have used other databases, but they don't have nearly the suite of applications and APIs to work with as RDBMS has.

It is such a mature product with the ability to handle many things. The newer version, 12c, has some features that people have been asking for. It was the same way going from 10 to 11 to 12, as they always seem to be listening to the customers and adding in some more features that they need.

With Oracle, the complexity of Database makes it a little bit more cumbersome. You're going to generally have more of a senior DBA to handle the intricacies when you get a large, very high, and intensive database that needs to be up all the time. You have to have a little bit more expertise in there.

We've had no issues deploying it, but, again, it requires expert administration from a more senior DBA.

Usually, you don't see any stability issues, but that really depends on the level of expertise of the DBA handling it.

There are no scalability issues, so long as the DBA is experienced.

The more expertise you have, the more the interfaces and UI become straightforward and easier to use in the initial setup.

If you look at the price point with it and how they structure the licensing, it is definitely going to be one of the more expensive ones. You do get everything with it because they throw everything in with the kitchen sink. If they could pare down the solution, then you could just choose the pieces that you want and maybe pricing might be a little bit more along the lines of what customers could use. It is definitely on the more expensive side.

In terms of scalability, make sure it's going to be what you need. Know exactly what purpose you're going to be using your database for. I'm one of the few people who knows a lot of different kinds of databases and which is best for what you want to do.

Oracle Database has had a multiple-concurrent-user control system from the very beginning. Most enterprise database solutions have recently become aware of this. Oracle's approach was the true approach to isolate users. Databases have some isolation levels and some anomalies. Oracle's database has solved them in a very brilliant way. From the beginning, 20 years ago, Oracle solved those problems. It is the most ACID-compliant database.

It has a multiple-concurrent-user control system, and it is the most ACID-compliant database.

We have the opportunity to easily open service requests and get answers from the professional Oracle teams. We have the advanced customer support team in Turkey. If there is a problem, it is easily and elegantly solved. It adds value; we trust Oracle.

We have not been using the new release yet, we are running on 11g. We haven’t had much opportunity to deeply examine 12c yet.

See my comments in the initial setup section.

Oracle database is stable. When Oracle slows down or if you can't use data, it means you are doing something wrong. The architecture is in the logs, the logging mechanism. If you know how to configure the database, it is impossible for you to lose data. It has the Data Guard disaster solution.

The Oracle database was first designed by people who left the Central Intelligence Agency. They knew how to implement security in the core of the database. I find it reliable and stable.

We are using a three-node RAC database; it is highly scalable. If we want to add another node, we just buy the hardware and add it to the RAC system. It is highly scalable.

When you have Oracle products, you have the right to use the Oracle support. We are able to open service requests. If it is urgent, we can open level-one service request. Somebody calls you and tries to find a solution to your problem. It is very useful.

When I was hired by my current company, they were already using the Oracle E-Business Suite, which obviously works with same database.

I myself installed the RAC database. I migrated from the old system to the new system with RMAN. We used the Oracle recovery tool to install the RAC and migrate our data to the new RAC system.

For those parts, to be honest, Oracle Database requires more effort than the other databases. It is a little complex. You have to know what you are doing. With RMAN, recovery, backup and restore - those kinds of operations - are a little bit more difficult than with other databases. You need slightly more manpower to run an Oracle database than the other databases.

The Microsoft SQL database now has an option to deal with data anomalies, for example, lost updates. Lost updates are a kind of anomaly with consistency. How do you support this with consistency? Those are all design issues. Microsoft has very recently implemented it in their database. There could be some anomalies in the database. You have to enable this option.

Years and years ago, Oracle already had this implementation designed into their database. I was working at a bank before my current company. The reason why they chose Oracle was the approach to data consistency.

Oracle is the most ACID-compliant database, and it is the most professional proficient OLTP database in the world today.

Look at the prices for additional add-ons. For example, partitioning costs in Oracle are a little high and partitioning is a very powerful tool of Oracle Database. Be aware of that partitioning option.

Look at the disaster solutions, for example, because that involves a data dump. Look at whether it is SQL compliant or not.

Determine whether you really need an OLTP database. Oracle Database is an OLTP, ACID-compliant database, and maybe you do not need that; maybe you need some type of document-based database. It depends on how you conduct your business.

When I am looking at vendors to work with, tech support is very important. We are in Turkey and sometimes it is difficult to find a lot of companies. Oracle is very active in Turkey. In Turkey, the banking and telecommunications sectors are very heavily dependent on technology. Most of them are using Oracle technologies. Sometimes. we can't find support easily.

We also look for stability, of course.

It's the only database you can operate at a very high professional level and that offers what the customers need from the product, ACID.

It's a crucial and critical part of our everyday business. That's what it does.

Real zero-downtime patching, that's what I want.

When you have a fallback system with RAC and Data Guard, the autonomous help framework could support it, but collecting the logs and reading the logs is still a nightmare. Improving this would be very good. The way Oracle does it today is OK, with in-memory options, with NoSQL database integrated and so on, but it could be a really good feature for the future.

We have scaled it, but not to a very high extent.

I think as we start to get into the IT business more and more, we will see how we need it. We are now operating an Oracle RAC system, so we can scale when required.

Technical support is kind of different because at some point, you reach the point where you can't proceed any further with stand-up processes. You need to have context and background information about the company. We're lucky that we can get in touch directly with the development team. We get help there.

Normally we have very complex problems when we have them. When we communicate with them using the standard channels, it does not fit. But, as I’ve mentioned, we have the direct line of communication with the development.

It's like, how do you decide that you need electricity at home? It’s a given requirement from the business. We've been working with Oracle for many, many years and using the product for many, many versions.

We did the initial setup ourselves. We have a huge framework in which we did the complete setup. We installed the clusters. It was not straightforward. For such as huge company like ours, it’s not straightforward. There are too many management processes around and too many specialties in the company.

We do not have any other vendors on a shortlist at this time.

We have three flavors of relational databases: MS SQL, Oracle, and MySQL. MySQL should fit the open-source aspect, and then we have two huge relational databases. Therefore, MS SQL is more for the smaller deployment and Oracle is for the huge deployments. SAP release 3 runs on Oracle, too. It was in the company. We didn't decide to use Oracle or not. It was there.

We just offer it to our customers and they choose. The mission-critical stuff runs on Oracle.

It's very professional and there are good structures implemented there. When you are willing to pay, you can get everything. Basically, what you pay for with Oracle is the maturity of the product, and that is something you can rely on.

Know how Oracle works. They say it's always been like that: you first sell, then you fulfill. You have to know that and that it's okay. You have to know that the new features will not work immediately.

When we're looking at a vendor like Oracle, we look at two areas. One is the technical part and the other is that it's a huge company. When we have problems, there is a huge organization behind it that can support it. We have a lot of ways to escalate issues. We look for a really huge company with a lot of people with whom we can get in contact. When we go to open-source projects or to smaller projects and we have problems, it's not as easy. Communicating with Oracle is easier to manage.

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.

Especially with Oracle, you have the high availability features. That specifically is very interesting to customers. When it comes to DR, I don't use high availability. Nonetheless, according to different strategies, it also provides features such as recovery, not the same as production, in different formats. That's a good feature about Oracle.

I provide disaster recovery services; they should look at how to recover production systems during disaster recovery. They are not focusing on that. They don't do that.

I’m in this industry doing recoveries. I don’t see an feature to easily recover all of the databases, especially RAC systems. That’s where they could come up with some kind of snapshots or technology that would make recovery easy.

The stability is completely amazing. It's been the industry standard for many years, so it is very stable.

As far as scalability, we can go from two nodes to I don't know, maybe 256 nodes. We can scale out, scale up and so on.

Technical support used to be not that great, but they are changing. They used to follow the Sun model. They are changing; it's better now.

They have developed automated systems. You don’t do anything. Basically, you turn it on and it brings up all of your stuff. It's easy to use.

When they look at databases, I don't think people look at any other vendors. You have only Microsoft and IBM DB2, but they are not that good. No one goes with them now.

I think when it comes to the product, the mindset is switching. Oracle is like a legacy RDBMS. People are switching to open systems. We have all of the new SQL databases, with no license costs. Especially if you also look at cloud solutions, that's where I think you need to have NoSQL or the latest technologies. That’s where they need to focus.

I'm not an end user of Oracle. We don't run any products on it. We have thousands of customers, and they come to us for disaster recovery. That's our business. We use all of the database solutions. In a previous life, I was an Oracle DBA, and I know what it can be used for. It can store large amounts of data. You can do all sorts of RDBMS data features and it’s the industry standard; there is no other database that can compare to Oracle.

When I’m choosing a vendor such as Oracle, I look at the licensing; other costs; and the help from technical support and even from sales. Sales people say yes to everything, except when it comes to implementation. It shouldn’t be that way.

I can't think of any specific features that are the most valuable, but all the small things that Oracle does compared to the free alternatives, such as MySQL, are valuable. I do appreciate having that power to do it. Even though 90% percent of the time I don't use those features, it's nice to have them should I need them.

It actually kind of fractured our organization. Half of us use Oracle for some things and the other half use MySQL for the other. I really don't care; I use both. We use Oracle a lot for authentication. I can't think of anything specific that is all that great about it. I'm not bashing Oracle, I just can't think of anything. I can't think of anything that makes me think, “Oh, we have to have it.”

I can't think of any but I know my manager was unhappy with certain features that we use, but we had to pay for those features along with a bunch of other ones that we didn't use. He wanted an option to not bundle a lot of the features. Other than that, I don't know the specifics about what he was talking about.

It's got a lot of good features, but at the same time sometimes certain niche things aren't mentioned. Some things break and I don't know why. Then when I Google it, there are thousands of reasons why they break, so it takes me a while to really pinpoint why. Its optimization could be improved a little bit, but it's good for the most part.

It's very stable, we've had no problems with that.

For the most part, as long as you do your research and don't screw up your table structures, I don't have any scalability problems.

I haven't used technical support; every issue I've run into I've been able to Google it and figure it out. I haven't had to call in or anything.

I believe we used MySQL for a while, it was free and that was the only reason we were using it. It wasn't the most stable, it was a little slow, and it doesn't scale as well, so we decided to go with a more professional solution.

I don't know why we chose Oracle, but I know we were debating between Oracle, MongoDB, and PostgreSQL. For whatever reason, I'm not sure why my manager went with Oracle, but we did.

Take cost into consideration and pick whichever really suits your needs. Every single database has its strong and weak points. I wouldn't say it's an end-all, be-all solution, but it just happens to work for us.

I think that Oracle today is the most powerful relational database, especially for PCI compliance, high availability, and high performance. Those are the Oracle database features I most appreciate.

I am waiting for Oracle to provide an interface between NoSQL and the Oracle database, so I don't have to go deeply into NoSQL. I just need to have an interface between them; to use SQL language to check that NoSQL or Hadoop is not down, and so-on.

We have been using it for more than 15 years.

The most important down time you can have for developers is when we upgrade from one version to another.

Otherwise, we have not had any stability issues, especially with 10g or 11g.

It's a very, very strong database.

It is scalable, especially with RAC. We can add more had more processors on the machine and through Oracle, I can use only part of the CPU on the server, so I don't have to pay too much.

Technical support is good, very good. It's a little bit expensive, but very efficient.

Initial setup is not difficult. For me, it's very easy, because I have a lot of experience on it.

The important thing with Oracle is that everywhere you go on Google, you see a million people have experienced the same problem. You always have something when you have an issue.

You should buy this solution. That's what I'm saying, in my company, a very big company. Every time someone asks, that’s what I say, because I'm involved with Oracle a lot. That's normal.