Video : DBMS_CLOUD : Objects and Files

In today’s video we’ll demonstrate the functionality of the DBMS_CLOUD package, with specific reference to objects in a cloud object store and files on the database server file system.

The video is based on part of this article.

You might find these useful also.

The star of today’s video is Roel Hartman, who used to do APEX, but now just runs marathons I think… 🙂

Cheers

Tim…

Video : Oracle Database 21c Express Edition (XE) Installation

In today’s video we’ll demonstrate how to install Oracle Express Edition 21c on Oracle Linux 8.

The video is based on this article.

Here are some other things you might find useful.

The star of today’s video is Martin Widlake, doing his best Monty Python impression.

Cheers

Tim…

Video : Multivalue Function-Based Indexes for JSON_EXISTS in Oracle Database 21c

In today’s video we demonstrate multivalue function-based indexes for JSON_EXISTS, introduced in Oracle 21c.

The video is based on this article.

You may also find these helpful.

The star of today’s video is my sister-in-law and the queen of the database Maria Colgan. It’s a pleasure to be one of your unworthy minions… 🙂

Cheers

Tim…

Video : DML Error Logging

In today’s video we demonstrate DML Error Logging, introduced in Oracle 10.2.

The video is based on a section of this article.

The star of today’s video is Oren Nakdimon, who’s chilling in his garden along with the birds. 🙂

Connor McDonald has done some videos on this feature, which are worth checking out.

Cheers

Tim…

Video : Using Expressions in Initialization Parameters in Oracle Database 21c

In today’s video we demonstrate using expressions in initialization parameters, introduced in Oracle database 21c.

The video is based on this article.

The star of today’s video is Deiby Gómez, who is a fellow Oracle ACE Director, and was kind enough to take me sightseeing when I visited Guatemala for a conference.

Cheers

Tim…

Hey DBA, fix it, but don’t touch it!

Martin Berger posted an interesting tweet the other day.

“what’s the expectation a DBA should do when “something is slow” – but HW and SW is ok and DBA is not responsible (and must not manipulate) schema or statement?”

The thread includes some suggestions, but I want to come at it from a different angle…

I have a lot of sympathy for this situation. In my current role I look after a lot of databases that sit behind 3rd party applications. In many cases, that means we can’t change the code. We can’t play around with the contents of the schema, for fear of losing support. Our hands are, to a greater or lesser extent, tied. This presents an interesting problem because you’re damned if you do, and damned if you don’t.

Thought 1

My attitude to databases behind 3rd party applications might surprise you. I try to stick closely to what the application vendor recommends, even if I know it to be stupid. Why?

  • Support (1) : As soon as you do something that isn’t in the vendor’s recommendations they are going to blame that for the problem. They’ll ask you to switch it all back and test it, which is just a delaying tactic most of the time and really annoying.
  • Support (2) : You want the system to be as familiar as possible to the support staff and any consultants they send on site.
  • Support (3) : I would say go for the vendor’s preferred platform, even if it’s not your preferred platform. You want to be on the same platform as the majority of their customers. If most of their customers are using Oracle on Windows, I’m going to consider it. If most of their customers are on SQL Server, that’s what I want. Unless you’re a massive customer, you are going to be at the bottom of the food chain if you marginalise yourself. Having lived through the death of Oracle on Tru64 and HP-UX, I want to be on the “main platform” for the application thank you very much!
  • Sometimes their crap application expects the DB to be crap. I had one case where the vendor’s approach to gathering stats was extremely poor. I revised it to bring it into this century and the application died. Their bad code needed bad stats to work.

At this point I expect someone to say, “But Tim, you’re supposed to be good at this stuff. I would have expected more from you!” What’s my response? Walk a mile in my shoes. If you have hours to obsess over one system to make it perfect, great for you, just don’t come and work here! 🙂

Thought 2

When you buy a product it should be fit for purchase. Part of that is the vendor should be able to give adequate guidance on getting the most out of their system. Also, when you purchase a system, you should be doing your due diligence. Having written this, I understand it is a complete fiction. Why?

  • Everything works great on PowerPoint. Procurement seems to be swayed heavily by the quality of the presentations, not the quality of the products.
  • I don’t think many people really know what they are letting themselves in for until they are so far down the line, backing out would be too embarrassing an option.
  • Sometimes, the best product on the market is absolutely terrible. I have one in mind, which my colleagues will be able to guess, where we had a choice of two products, both of which were absolutely terrible, so we picked the least terrible. In a meeting with our IT director I said, you’ve heard the expression, “You can’t polish a turd, but you can roll it in glitter!” This product is the turd inside that glitter!

Thought 3

Even when it’s not a 3rd party app, you can’t always fix it easily. As an application grows it gets significantly harder to refactor pieces of it. Sure, you can change that little bit, but what are the knock-on effects? If you have good regression tests, great. If not, it can be a risky endeavour. I mentioned in another post it took about six months to find some of the performance issues brought about by an upgrade from 11.2.0.4 to 12.1.0.2. It was stuff that had been missed during the testing and only ran once a year. The bigger the application, the easier it is for something to hide.

Even if you can refactor, do you have the time and resources to do it? Applications aren’t static. Sure, there is pressure to fix performance problems, but there is also pressure to add new functionality. What’s best for one group of people may not be good for others.

Thought 4

Martin’s tweet exemplifies the misunderstanding most managers (not him) have about databases. There’s rarely a magic button you can press that fixes performance problems. The vast majority of the time it comes down to bad database design and/or bad SQL. When you can’t change either, you don’t have much choice other than to wait for the next application patch/upgrade from the vendor that might fix it, or throw hardware at it on the DB layer or the App layer, depending where the problem is. {Insert “Run it on Exadata” comment here!} I really don’t think a lot of people outside the database world understand this!

Oracle has a lot of goodies that can be used to mitigate terrible applications without having to touch them directly. Update: I’m not trying to make out all these features don’t come with their own set of issues too. 🙂

But the real solution is to do proper database design, write good SQL, and write good applications on top of that. Performance is a development issue, and we are all developers now. Yes, even you DBAs. 🙂

Anyway, just some thoughts on the situation Martin found himself in, and I find myself in all the time. 🙂

Cheers

Tim… (Chief Presser of Magic Buttons)

No DBA Required?

Kellyn Pot’Vin-Gorman put out a nice post a few days ago which you can read here. It talks about the future of the DBA, especially in the light of Oracle’s new “fully managed” Database Cloud Service that will be announced soon. I pushed out some links to the post on social media with a “Just Read” message, as I sometimes do, then was hit by a wave of questions and comments about it. I think I’m on the same page as Kellyn where this is concerned and I’ve been saying similar things for quite some time.

I’ve also talked about how the world has changed for PL/SQL and SQL developers.

The reactions I’ve received following all these posts, as well as the comments about Kellyn’s post, can be broken down into the following categories.

  • Denial : The [Apps] DBA role will never die!
  • Panic : Quick, tell me what I should learn today before my family is out on the street.
  • Pragmatic: My role as a DBA has evolved so much over the years, and will continue to do so. I have to continue to adapt or die.

I think from my previous posts you will know I’m in the Pragmatic category. The type of work I did 20 years ago, whilst calling myself a DBA, is drastically different to what I do today. In 10 years time my role will be totally different, but I will probably still call myself a DBA (Do Bloody Anything).

At this point someone will chip in with, “We will never move our databases to the cloud so this doesn’t affect me!” This is naive for a couple of reasons. First, you will move *some* things to the cloud. It will happen! Second, the changes to the DBA role will happen regardless of the cloud. Automation is the thing that is altering the lives of DBAs and SysAdmins. Cloud is just another form of automation. If they haven’t already, your company will have to get on board with automation or die. In addition, the products you use will evolve over time, as they have been for years.

You can look at all this from a couple of angles.

  • OMG! I’m going to have to learn something new. What a bloody nightmare! I was hoping to do the exact same thing every day until I die!
  • OMG! This is brilliant! There’s loads of new stuff to learn! When I know this new stuff I’m going to be even more valuable!

Take your pick… 🙂

Cheers

Tim…

PS. It will be interesting to see what Oracle actually come up with at the end of all this… 🙂

Update: Loïc Lefèvre just sent me a link to this article, which is pretty cool!

Update 2: You might want to read this from Thomas LaRock from the SQL Server camp. 🙂

Database Administration : Dead or Alive?

I get this type of question a lot at the moment. It’s not surprising as I’ve done a few things of late that seem to have got people a bit riled up.

  • During my cloud database talks I’ve been saying things like, if you think a DBAs job is just to install, backup and patch the database, the cloud has taken your job.
  • I happened to mention the Oracle Cloud Apps DBA role does not exist. I thought I made it clear what I was saying, but a number of readers thought I was saying they shouldn’t go to work next week as they’ve been fired.
  • I’ve recently been doing some sessions with a title beginning with “Making the RDBMS relevant again…”, which suggests maybe it isn’t currently relevant.

I’ve been doing Oracle database development and DBA work for nearly 22 years. In that time the job of an Oracle DBA has changed a lot. Despite this, having people who understand what is going on below the surface has remained in demand. If you keep trying to be an old-school DBA you are going to find yourself in a very dark place very quickly. If you keep your ear to the ground and try to move with the times there will always be a role for you. Good people always land on their feet.

The way you move depends on your interests and the demands of your company. Some will move closer to an architecture role related to the infrastructure, which is pretty important when dealing with the cloud services, docker, DevOps, continuous deployment etc. Some will align themselves more closely to development, which is of greater importance in the new world. Others will completely move away from RDBMs into other technologies related to data or elsewhere.

The next question is typically, “When?” I’m not saying we should all run around screaming and pulling out our hair, but we should also not turn a blind eye to the way the world is changing. I can pretty much guarantee there will be comments by people telling me I’m wrong and the DBA role will exist forever, to which I will reply, “Denial is not just a river in Africa!” 🙂

Some companies, especially those that are more development led, will transform rapidly. DevOps, continuous deployment and technologies like Docker have the power to transform a company rapidly, whether on-prem or on the cloud. In all cases, someone needs to help build and maintain the layers that contain databases and app servers, and that could be you, but I don’t see the same volume of work we currently have, because if done properly it should be a build once, deploy many approach. For some companies that are into automation, this is already a reality. Very soon it will be true for much more of us.

Some companies will be slow in moving forward and their staff will wonder what all the fuss is about, until they apply for their next job and realise there isn’t one for them!

Having said all that, I did an “unconference” session at OOW in 2007 called “The Oracle DBA… A dying breed?” and we’re still here now. The important point is you need to take responsibility and shape your own destiny. Don’t sit idly by an watch the world take your job. It’s easier than ever to learn new things and prepare for the future, so do it! 🙂

Cheers

Tim…

The Cloud : They took our jobs!

The title is of course inspired by “They took our jobs!” from South Park.

I’ve been doing some cloud-related talks recently and a pretty regular question is, “How is this going to affect my job as a [DBA | Sysadmin]?”

My answers usually include some of the following points.

  • Back in the old days, we used to spend hours obsessing about redo and rollback/undo and sizing of the individual parts that make up the SGA and PGA. Keeping on top of some of this stuff was a full time job, even for a small number of databases. Over time Oracle have added loads of automated features that mean we don’t have to worry about this stuff for “most” of our databases. So that means less DBAs right? Not really. We are just expected to cope with a lot more stuff now. Rather than looking after 3 databases, we look after hundreds or thousands.
  • For Infrastructure as a Service (IaaS), the cloud is just a basic hosting company. You are still responsible for all system administration and database administration. A move to IaaS doesn’t affect jobs at all. If anything, it probably adds to the demand.
  • For Platform as a Service (PaaS) offerings, like Database as a Service (DBaaS), things may be different. Your level of interaction with the OS and database varies depending on the vendor, but in some cases, you will have zero access to the OS, so there is no system administration, and the level of control over the database is limited. Surely that affects jobs? Well, once again, this has just made life easier, so your company can do more stuff and you will probably be expected to do more.
  • As far as Software as a Service (SaaS) is concerned, as a customer there is no access to the infrastructure, so there is no DBA or sysadmin work. If you want to look after the guts of Fusion Apps what’s wrong with you get a job with Oracle. 🙂 Even if you don’t have access to the guts of the SaaS system, you are still going to spend a lot of time designing systems to interact with it!
  • The cloud means I no longer have to install operating systems and databases! Well, sometimes I really enjoy doing donkey work, but if you’ve not automated most of this stuff, you are really living in the dark ages. If you have automated it already, then the cloud isn’t really any different to what you are doing now.
  • What the cloud will not do is understand your custom applications and provide the skills needed to diagnose problems and advise on solutions. All the interactions with your developers and support folks will still be necessary. I can’t see a cloud service helping with this sort of stuff ever. The role of a development DBA and the crossover between functional and technical knowledge is actually far more valuable than being able to install a bit of software.

There is no doubt the cloud will affect what we as DBAs and system administrators do, but our jobs have been constantly evolving over the last couple of decades I’ve been involved in IT. As Francisco said recently, “These days, DBA stands for Database Architect”, which I think is kind-of true. A decade ago I just did Oracle databases. Now I do Oracle, SQL Server and MySQL databases. I look after WebLogic, Tomcat, IIS and Apache App/Web servers. I’m helping to set up load balancers. I get involved in infrastructure projects for applications and middleware. It’s not that I’m awesome at any of this stuff, but as a DBA and/or system administrator you get exposed to so much, which makes you an ideal resource to help with this architectural stuff.

If you think a DBA just installs Oracle, creates databases and checks backups, your job will be gone soon. If you are a system administrator that just installs operating systems and does patches, your job will be gone soon. These are trivial tasks that anyone can learn in a few weeks, so you should hardly be surprised they can be automated out of existence. If instead you concentrate on the skills where you add true value to your company, you will be in demand for a long time!

I know it’s a bit of a random post, but I hope you can see where I’m coming from! 🙂

Cheers

Tim…