Oracle Database Reviews

If you remember the old Saturday Night Live skit by the baseball player, Oracle's been very, very good to me. I chose to work with databases and specifically Oracle right out of college, the 80s. It was a right career decision. It took me this far. I'll probably get to my retirement on it. That's a pretty sound technology. Had I picked some other technology to bet on, I probably would've had to go through several different learning iterations. The Oracle Database scales well. Every time there's a new version they add the features that you are wishing they would add or finding that you need. They stay ahead of the game. A lot of times you'll talk to one of their product managers and you'll say, "Well, partitioning is great, but if it only did this," and they'll say, "Oh, well if you sign an NDA, I'll tell you." Legitimately, they've already thought of it and they're developing it, and a lot of times if you get into the beta program, you can participate in the development of those features. That's really unique. It's much better than say a community preview edition like other vendors would do.

The beta program, you sign up for and you're very proactive with it and you have direct access to people who are working on the beta itself. You can help drive the product direction and that's kind of fun.

Right now, one of the things I've been using a lot of is the In-Memory column store, which is a new Oracle 12c feature and it's gotten a lot of press. It's a great feature. If you remember a few years ago, Vertica and some other column oriented databases came out and it was all the hot rage. Now, lo and behold, starting in Oracle 12, I can have column oriented data storage and it makes my memory more efficient so I can fit more In-Memory. It makes the queries faster and it makes more queries faster because of the memory being more efficient, there are more queries that can benefit from the same amount of memory. It's literally you turn on a configuration parameter and you say alter database or table and say that that table was In-Memory, and you're done. The database does everything. It's very simple to use, very powerful, and it's exactly what people were asking for a few years ago.

The same is true, I attended some of the Oracle 12c R2 sort of pre-announcement sessions and while we're not allowed to talk about what we heard, I can say for a fact that some of the stuff that they talked about was exactly the same type of things where there's a feature that was introduced late in 11 or early in 12 and you thought, "Boy, I hope this is step one and they're going to do step two and step three." They have. Now it's not public yet, but it's very reassuring to know, again, they understand the database market and well enough to develop the features just in time.

I know that a lot of people like Oracle Enterprise Manager and it's capable and it's great, but for a lot of tasks it's overkill. They came out with this new tool in 12, the OEM Express. I would like to see that tool persist. Oracle does on occasion have a bad habit of developing a tool, I'll go back to Oracle 8 on Windows, they had a really cool little GUI for developing DBA and then it was gone a version later. I'm hoping OEM Express sticks around. I'm not saying that it competes with OEM, but a lot of times, if all I'm doing is going in and adding some space to a table space or creating a user or do something simple and easy, that flash interface local on my web browser runs 100 times faster and it's easier to find stuff because there's less features in it, so you don't have to look as far.

Oracle stability's a funny thing. I know companies who do not have any database administrators. Stability in those shops is sporadic, and it should be. You need a database administrator to oversee your databases, just like you need a manager to oversee your people. It's an asset. In fact, your data's your most important asset. You sure as heck should have a specialist.

Oracle's a very powerful, robust, capable database. However, in order to be powerful, capable, and robust, it's a little complex. You need a database administrator. I'm not saying you have to hire a six figure guy, but you've got to have somebody. I know a lot of SQL server shops where they also don't work with database administrators. They can get away with it because the database isn't quite as industrial. I'm not going to build petabyte databases in SQL server but I am going to build it in Oracle. If I've got that size, it helps to have a DBA around.

You can start with the basic database, so the Oracle single instance. You can scale that pretty much to whatever size, symmetric, multi-processing processor you want to put it on. If that's not going to scale large enough for you, then you can do RAC clusters and you can build basically a little database mainframe. If you've got extra money to spend, I've got this wonderful solution called Exadata. I wish that Exadata was it, that that was the only thing Oracle had to offer. It's that far superior to the standard database, but it requires both hardware and software and there's special licensing. You can't build an Exadata at your own and just get the software. It is just standard Oracle with some hardware tricks. That's impressive, that you can make a database machine that outruns anything and it's still the standard database. They didn't have to really change it.

Rating: I would give it a nine. The only reason I don't give it a ten is because they do keep inventing and adding more stuff. The stuff that they told me yesterday and today that'll be available in the next release, let's say next year, not only is it stuff I wanted, it's stuff I didn't even dream of. I'll be excited. If I had those features today it'd be a ten, but they're on top of it.

It's very stable. It's a database that's easy to recover if you need ways to restore and recover, and I like the performance.

The feature that I would like is a way to grant select tables of one user to another without needing to specify each one separately, or creating a trigger to do this automatically. Being able to grant all privileges of some object or some schema to another schema would be good.

Also, I would like to have a better Export Data Hub. The old export allowed you to export remotely, and Data Hub is just locally using directories or a database link. I would like to have Export Data Hub using the SQL match instead of directories or another database. Just like the old export.

I've been using it for around 10 years.

It's stable.

It's scalable. When I need to deploy other databases or other schemas, it's very easy to do. Now with the multitenant model, it's even easier.

They have this thing that you can only create a P1 for something that is harming your production. Sometimes I would like to create a P1 for other problems, but I can't, because it's something that is putting my company at risk. They are good in supporting us, but I don't like the policy of P1, P2, P3, or P4.

It's very easy to set up, not for someone who has never worked with it, but if you had a junior or someone a little more experienced than a junior, they are good enough to deploy.

I think it's very expensive when compared to the others. Depending on the size of the company, smaller ones will not choose Oracle because they can get fixed solutions or less expensive solutions. If I were Oracle, I would create a solution that would serve these small companies for a better price, maybe with a lot less options, but not as expensive as some other options.

I think security is a concern in the database, so you need to take care before granting some privileges to a DBA and it can become very easy to break. I would say to be very careful before granting permissions or configuring the database.

I'm going to be discussing the enhancements to the PL/SQL language in what I'm going to call the bad old days, what we did was we put all of our application code and all of our application objects into one schema. What happened when you would do that is you would have say a SQL injection bug in one piece of code and you could easily point it to very sensitive information. As a matter of fact, I believe Barclay's said 97% of the data leakage is from SQL injection.

Oracle made an enhancement to the language. They added two things that were very powerful. One was the ability to add roles directly to a PL/SQL package. The other thing they added was an accessible by clause such that if I am going to have objects in one schema, instead of granting access to those objects to an entirely other schema such as your app code, I can just grant the access to that object to the program that actually calls it so I could have sensitive objects granted to a sensitive access code. Anybody else tries to get to it, you're not going to be able to get to it.

Then they added one other thing because what you want to do is you want to layer your security. Then they said make it accessible-by. When you accessible-by clause in, the object that is granted access to it, it'll execute, but if anybody else tries to execute that package to get to the object, they're going to get failures. That is what's got me most excited right now about the Oracle language and what they've been working with.

The value is in locking down your data, every time we turn around, we see on TV, GAO got hacked. Somebody's losing their information. You have companies out there going, "We'll protect your private information if you ever lose your information." We shouldn't have to do that. As stewards of this sensitive data, we need to build a security solution around what's sensitive and now Oracle's given us more and more powerful tools in order to implement that.

The biggest benefit is you're closing holes to SQL injection bugs. If I have a program, say program unit A has a PL/SQL injection bug, and you haven't implemented this, if I can inject into A, I can get to the sensitive information. But now by granting the role to the package and also granting accessible by, saying this package is only accessible by this other package, if A tries to get in, it says no, you don't even have rights to execute the code to get to the data.

In the next release, I'd like to see the ability to shred ghost data. I'd like to see the ability to when you run a data pump export of encrypted data and you did not specify encrypted in the command line, the data will be saved unencrypted and it'll spit up an error message, but it's just a warning saying, "otherdata is unencrypted." That does not get into the audit trail. That needs to be in the audit trail so an auditor can later go and say, "Why did we save data unencrypted that's sensitive?"

The stability is fabulous. I have one customer that has scaled this out and the application's now reaching over 100,000 users and we have not had any problems with it.

Oracle's technical support, I use it about once or twice a year. Normally, if I call support, we've got a real problem and they've always been very helpful.

My current customer, it's because a law was passed. This is a new architecture. Similar in terms of the language, but it's enhancements to the language, but what we're doing is building an architecture on top of what the language is now giving us.

It is much easier to set up this solution, designing it in from the beginning because if you try to go back and retrofit your code, it can be done, but it's much more labor intensive. You should always build your security in upfront. Retrofitting code, it's difficult. It can be done because you have to separate your stuff out and sometimes, it may seem like trying to pull the salt out of soup. It depends on just how tightly integrated it is.

Considering the work was already being done in the Oracle and PL/SQL, this was just an enhancement to what we were already doing.

I would give it a 9 because when we first started doing it, we found just little irritating niggles. I wish they had implemented it a little bit different, but overall a 9.

Absolutely do it because if you value your data, you want to be able to secure your data from SQL injection flaws.

The powerful SQL language for working with, analyzing and manipulating lots of data. The concurrency and consistency model that allows many simultaneous users with little or no locking. The extensibility using PL/SQL and Java to extend legacy application with modern features like webservices via the database.

Rewriting legacy procedural modules to SQL with analytic functions has on several occasions turned multi-hour jobs into few-minute jobs. High concurrency enables sales persons in shops to service customers swiftly with no waiting even on peak days with several sales per second. Even though legacy application cannot interface with external services, the database is capable of doing so, which enables the business to get new ideas without thinking of technological hindrances.

There's not much - new features come along in every version helping to keep up with
technological advances. There are some small technical issues such as support forwindowing clause in LISTAGG function and a few similar small issues in SQL. There are a few nice-to-have extensions, like allowing external table syntax on the content of a CLOB.

I've used it since 1996.

Some of the time, a Real Application Cluster version was used, which turned out on very rare occasions to performed unmotivated failover to other node. The problem really was sub-optimal coding of the legacy application in the use of the locking methods of Oracle, which was magnified when propagating locks to other nodes, however would have been nice if RAC could have handled it, even when sup-optimal. After switching some years ago to a single server non-RAC solution, the database has been rock steady - only instabilities was when O/S or hardware failed, not the database.

Highly knowledgeable and competent tech support - once you get past the first level and get the case assigned to the right people. However, it can take quite a bit of time to explain details to first level support and gather debug and log information, that in some cases aren't necessarily relevant but is merely correct procedure in order to get the case assigned. On the other hand, many key Oracle people engage in the community, so a finicky question about a PL/SQL detail might get attention and answers from product managers themselves.

Before 1996 we used a legacy application, but it would locked on a table level. That meant practically no concurrency, for example phone sales people could not enter order data while talking to the customer but wrote on paper. Then one guy would enter all orders later. After a demonstration of Oracle database giving high concurrency, it was very easy for my boss to decide to buy Oracle.

An external consultant was hired for the setup and there was no trouble with the database setup. The legacy application needed a bit extra setting up to get it to run properly with Oracle, but that was not the fault of Oracle.

Bargain with the sales representative for good discounts - particularly if you buy several licences at once. But beware when buying multiple licenses together you get them on a single CSI, which may give trouble in future if you need to cancel one license out of the total, as that in principle means cancelling all licences and renegotiating so you may get new prices with less discount on the yearly support fees for the licences you have left. Research all the things that actually is possible with the basic licence so you get your value-for-money and only pay for options if you really need them.

There weren't many options at the time. A database supported by the legacy application had to be chosen, and the native legacy database just wasn't up to concurrency demands as described above, so Oracle was the other choice.

Oracle database can do many things that you may think it is necessary to supplement with other products. Look into how you may use all of the features to get value-for-money - then it might turn out in the long run to be cheaper than having to integrate multiple products.

• Online RMAN backup & restoration
• Active High Availability i.e. real application cluster
• Disaster recovery solution (physical and logical standby)

It increased operational efficiency manifold, as it offers lot of features automating operations, and faster failover mechanisms (i.e. almost zero data loss) with smaller RTO and RPO, helping Business Continuity.

It’s easy to find performance bottlenecks, I would prefer it to have a faster read time performance, especially considering read performance of NoSQL systems nowadays.

I’ve used it for seven years.

There were no issues with the deployment.

We've experienced no issues with performance.

It's been able to scale for our needs.

Their tech support it good.

Oracle Database was found to be the most mature solution, in terms of features it offers. Hence, we chose this.

I would rate it mediocre, as it requires knowledge of operating systems and servers. Some people find it difficult due to the lack of OS knowledge.

We did it in-house. You need to do your homework, and read the standard documents thoroughly before proceeding with setup.

It is on the higher side, so it’s better for big enterprises. However, small and medium business can explore cheaper versions of the same product, which doesn’t offer all benefits of the enterprise version, but it will still be good enough compared to almost any other database solution.

Although it’s easy to operate, it needs expert hands, as it is different, and in fact better with a lot of features, compared to cheaper alternatives. So, good skills should be deployed to effectively use the features of the product for a better ROI.

1. Adaptive Query Optimization - enable the optimizer to make run-time adjustments to execution plans and discover additional information that can lead to better statistics. This new approach is extremely helpful when existing statistics are not sufficient to generate an optimal plan.
2. Pluggable databases - allows you to put 253 databases into one instance of Oracle.
3. Redaction Policy - The Oracle Database 12c provides runtime protection of sensitive data. The stored data remains unchanged, while the data to be displayed to the end user is transformed on-the-fly before leaving the database.

I have worked on an Oracle databases that processes over 100 billion rows daily as well as provide reporting in a timely manner to end users. Oracle's years of maturity and continuous improvement allows the database to perform exceptionally well especially on Oracle's Exadata hardware.

I would like to see Oracle Business Intelligence and maintenance tools incorporate virtual reality interfaces so DBAs and end users could interact with the database.

I have used Oracle over 15 years and the database is very scalable, reliable, and well supported.

There were no issues with the deployment.

We have had no issues with the stability.

We haven't needed to scale it.

The main, most important feature is the integration of the database, security, and performance. Those are the three main features. They have evolved it very well since version 6. It used to be rule-based, now it's cost-based, which is great because there are so many routes to bring in the data. It's a really complex architecture, and the way Oracle has done it is really good.

I work with a couple of other databases too, but with Oracle, it allows you to drill down to a very small level inside the database and return a result that you want. That's another pretty good feature.

Also, Database has low-level security through a virtual private database. Within the same database, we can show two businesses simultaneously without having a different architecture. This really helps us.

A lot of things like a low level security. One of the features that we use virtual private database, which is a low level security. Within the same data base we can show two businesses at the same time, without having a different architecture. It actually helps us.

It's beneficial for our organization because we have a lot of financial data where it has to make sure that something came before on the master data layer. You have to have a node created before you insert the data that leads it to the node.

When there is the high insertion of data and bursts of insertions, Database has to manage the integration, but the way it tries to maintain all the integrations is not necessary. There's a way to de-normalize all this, but not if an application is already downloaded. Database has a lot of limitations, especially when you have a huge data insertion that you're trying to query. That really becomes a limiting factor with Database.

I've been using Oracle products for 22 years.

We have no real issues with deployment.

It's one of the most stable database that I work with. They have been improving with every version. As far as stability goes, I give a very high marks to Oracle.

There are ways you can scale it, but one of the limiting factor is the way Oracle licensing works. The moment you try to out scale it vertically or horizontally, you multiply the Oracle licenses, and a lot of customers are looking into that. How do we optimize those with the performance that you need?

The problem is the way the technical support works. A lot of people try to pass the ball around, and that's a lot of challenge with management of all that. Most of the time, if you really want to work on something you have to raise it to Level 1. You've got to escalate, otherwise things doesn't get worked on. If it's a critical thing, there's no other option.

The initial setup was straightforward, but maybe I'm so experienced that I don't have many issues with it. A new DBA may have a different view of the setup. I would suggest, however, that Oracle should develop a feature in Database that lets you know which products you have a license for and which ones you don't during the setup.

We implemented it with our in-house team.

It's a good, stable system. When it comes to Oracle, you need to understand what to use, how to use it, and look into the cost of it, which is very important.

I really like the way Oracle Database handles crash recovery. I find that that's the most valuable feature among the other databases that I work with. I have yet to see a time when my database crashed, for whatever reason, whether it be node crash or server crash, and Oracle didn't clean it up and it come back online as before. The way Oracle processes cleanup itself and comes back online is great. If one of the Oracle nodes in the cluster goes down, the others keep running, which we're very happy about.

It's a good, solid database architecture, one of the best in the industry. With it, we also have a good partnership with Oracle, who provides us with great support.

It's so huge, so vast. If we're talking about security, there could be improvements. Also, we'd like to be able to come up with migration strategies that involve less downtime. That's one of our struggles with it, particularly when we're migrating sizes of several terabytes. We can't afford to have our agents down for twelve hours at a time to do the migrations. So I'd like to see some more innovative ideas, some more improvements in that area to help us out.

We've had no issues with the deployment.

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

We've been using the add-node functionality. We started with a few of the clusters, the RAC cluster, with two nodes, and we have expanded them to five. We are going to what we call the super-cluster design.

The initial setup is intuitive, though I can't say it's necessarily easy. It's just that I've been doing it for several years now.

We do implementations with our in-house team.

I think Oracle is the way to go. It's a solid RDBMS. There's lots to learn.