Oracle Database Reviews

The most valuable feature is the scalability of the database.

I see an increase in efficiency and reduction of man hours. There is faster response time on the queries and better performance on them.

I would like to see improvements with caching. I know there are some technologies within Oracle which could deliver more in-memory caching.

We looked into Microsoft SQL. We didn't like it nor see it as an enterprise-level solution. Oracle has more features in terms of administration.

I would recommend this solution based on the track record, performance, and the support. It's really easy to figure out. I wouldn't think anybody needs any training on it. The basic knowledge of any database should be sufficient.

Container Databases (CDBs) help reduce server sprawl and manage resources in a much better way. It's a feature that consolidates all your application data with Oracle database metadata, still keeping a strict role to manage each of them respectively. With the CDBs, it's become easy to deploy, clone and administer Oracle databases.

Application Continuity simply helps application to be highly available by doing a lot fewer application code changes.

It helped consolidate most of our database servers, and saved annual maintenance costs of up to 23% on physical servers.

Oracle could provide a few extra features as part of the standard offering in their main license.

I have used it for a few years.

It depends on the kind of database solution you are applying, but I have not yet encountered any stability issues.

10/10 MOS Support is actually something you can heavily rely on.

Technical support is 9/10, very proactive and very helpful.

Use licensing with caution, read the fine print. :) ?This is an important point and usually it's not skipped by the companies paying for the license. Nonetheless, Oracle supports your applications and database only if Oracle has certified the ?hardware and software that the companies have used to build and deploy their applications and databases on; which basically means that you have to use industry-standard hardware and software.

It is possible that your hardware is not supported or has been desupported for a specific version of the Oracle product, so just remember to read the fine print before you deploy your applications.

MS SQL Server was also under consideration, but we had more Oracle DBA's to work with and Oracle’s training requirements were also more favorable.

• Performance
• Durability
• Security

For a long time I've been working as a performance tuner for Oracle and Java. The tuning of the performance is very important for me.

I want the price to be lowered.

Oracle solutions are the most used, so we don't need to do verification of the product on our own. We can assume that the product's reliability is high enough. Based on Oracle products we are able to run our own developed applications at very high performance levels.

What we do is that based on a certain understanding about the product speck, based on the maximum transaction we can assume for our businesses, we are going to decide the sizing and then we confirm the capability and we decide the threshold. Then after that we do the scale up. Based on the recent cloud environment, I cannot really say that it's easier for us to do the scale up.

The people who used to work in Oracle are responsible for the tentative troubleshooting at the 1st stage. Then if we need more further investigation, then we exchange the technical support contract. Based on that agreement they will provide us with support. Once we purchase the product from the Oracle, then they offer the knowledge. The structure of the knowledge is quite well-shaped.

For colleagues who are in the financial business and are looking into what kind of product they want to use for their databases - I would recommend using the Oracle Database because in terms of the security and in terms of the audit process it's top notch. When it comes to audits, as long as we say we are using Oracle Database, then they give us a certain assurance. They're confident about it.

It's stable, scalable, transportable – all of that combined together; it's a reliable platform; more knowledge base; and more pertinent support.

I think Oracle could provide some more user-friendly, front-end toolsets. Even though it's for techies, that would be nice. I know they have some, but those are all licensed products.

I have been using Oracle Database for 20 years; a long time; since college.

Knock on wood, there hasn’t been any downtime to the point that is noticeable, but we do plan downtime to do stuff; it has seldom choked up on us.

I think it will meet our company’s needs going forward; so far, looking good. 12c has more promise and cloud is the next frontier. Being in healthcare, just being cautious, but I think there are signs they are getting ready to move to the cloud; gradually, not 100%.

Technical support is good. It should be more direct, but now, it's a little indirect. I still rate them high. When I need them, I can demand and they'll respond. Sometimes, the challenge is the time zone. You have to be careful when you're opening a case; how to make sure you have the right people in the right time zone.

This product came in before I joined my current company. I think it was influenced by their ERP system which they brought over in 1998. Lawson recommended running on Oracle.

Setup is straightforward, but it requires some knowledge. Otherwise, it will turn out to be complex. It's not like anyone can do it. You have to know what you're doing. That involves training and knowledge transfer.

Everything is good but pricing-wise, it's still struggling with that. It's very difficult to justify their costs sometimes in the board room.

We also use SQL Server, MySQL, and a little bit of MongoDB.

I would recommend the products I have experience with. I don't just say yes or no, or give just one or two options; I give you a bit more. I recommend the product I have, Oracle RDBMS Suite. I think they're still trustworthy, if not more.

When I select working with a vendor like Oracle, I look for the sum of their accomplishments. I don't really go for companies because they have been in business for 50 years. I also look for agility; what they bring; transparency; the offering, of course; what they're bringing in and the ideas behind it. Is it going to be sustainable for five years or more? Is it going to diversify itself across the industry? I rate thsee factors high.

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.