Tag: poll

Update Oracle Database Time Zone Files (Poll Results Discussed)

In case you didn’t know, countries occasionally change their time zones, or alter the way they handle daylight saving time (DST). To let the database know about these changes we have to apply a new database time zone file. The updated files have been shipped with upgrades and patches since 11gR2, but applying them to the database has always been a manual operation.

With the recent switch over to daylight savings time in the UK I decided to post this question on Twitter yesterday.

How often do you update your Oracle database time zone files?

We get less than 6% of people updating their time zone files on a regular schedule. Nearly 45% who only do the updates after a database upgrade, and nearly 50% of people who never do it at all.

I can’t say I’m surprised by the results. In terms of the reasoning for these responses, I’ll reference some of the comments on Twitter.

Regular Schedule

“Every ru patch, also thanks to 19.18 it is included now and with out of place upgrade and autoupgrade, i dont do it anymore 🙂 all automatic.”

Mustafa KALAYCI

If you are using AutoUpgrade to patch to a new Oracle Home, then applying updated time zone files is really easy. Before 19.18 it’s just a single entry “timezone_upg=yes” in the AutoUpgrade config file. From 19.18 onward the update of the time zone file is the default action (see here).

So interestingly, there may be some people who don’t know they are applying an update of their time zone file, who actually are now…

After Upgrades

This feels like the natural time to do it for me, and it seems many other people feel the same.

As mentioned previously, AutoUpgrade makes it simple. From 21c onward AutoUpgrade is the main upgrade approach, even for those that have resisted using it for previous versions, so this question goes away from an upgrade perspective.

We can specifically tell it not to perform the action using “timezone_upg=no”, but I’m guessing most people will just go with the default action.

Never

“NEVER. As an American-only company with very little need for time-specific data, quite unnecessary. Horrible design with no rollbacks and headaches w/data pump. Just not worth it if possible to avoid”

Taylor

I totally understand this response. Many of us work with systems that are limited to our own country. Assuming our country doesn’t alter its own daylight savings time rules, then using an old time zone file is unlikely to cause an issue.

When you consider the number of people that run *very old* versions of Oracle, you can see that using old versions of the time zone file doesn’t present a major issue in these circumstances.

With reference to the data pump issue, I’ve experienced this, and it was also picked up in the comments.

“My hypothesis: Most do it when datapump tells they need to do it to get the import file they just received to load”

Connor McDonald

Offline/Online Operation

The point about this being an offline operation was raised.

“Well it is an offline operation, so pretty exceptional thing to do. Only in a rare case where some feature requires the upgrade – like DataPump failing or query over dblink failing.”

Ilmar Kerm

Downtime is never welcome, but it was also pointed out it can be an online operation in 21c.

“Offline will be a thing of the past…

https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/TIMEZONE_VERSION_UPGRADE_ONLINE.html”

Connor McDonald

Conclusion

It seems like the time zone file version is not high on the list of priorities for most people, providing it is not causing a data pump issue. I totally understand this, and I myself only consider it during database upgrades.

I always like reading these poll results. I know the sample size is small, but it gives you a good idea of how your beliefs compare to the wider audience.

If you are interested to know how to manually upgrade your time zone file, you can read about it here.

Cheers

Tim…

Separation of Duties (Poll Results Discussed)

On the back of the recent patching polls I asked a couple of questions about separation of duties.

As always, the sample size is small and my followers have an Oracle bias, so you can decide how representative you think these number are…

Separation of Duties

Here was the first question.

Regarding GI/DB, do you take advantage of separation of duties? Meaning separate people/groups looking after GI, ASM and DB on the server. Or does the DBA do all of it?

This is exactly what I expected. For the vast majority of companies, the DBAs are responsible for the Grid Infrastructure (GI), Automatic Storage Manager (ASM) and the database (DB).

When Oracle first started floating the idea of separation of duties it kind-of surprised me, as I had never worked with a company that cared about it. Sure they have System Administrators that look after the OS, and maybe provision new disks on the server, but I have never experienced a situation where anyone other than the DBAs do anything with the Oracle side of things.

Don’t get me wrong, if that’s what a company wants to do, it’s good that Oracle make it possible, but I think the vast majority of people just don’t care! What’s more, I think it’s likely to cause more problems than it solves.

GI/DB Ownership

This was the second question, which was suggested by Aishwarya Kala.

Regarding GI/DB installations where the DBAs do all work on the system, have you split the ownership of the GI and DB installations between different users?

It’s interesting that nearly 90% of people have the DBAs doing all the work on the servers, but nearly 50% still split the ownership of the Grid Infrastructure and the database software.

Back in the day nobody talked about separation of duties and the “oracle” OS user owned everything. When discussing separation of duties, Oracle suggested the Grid Infrastructure should be owned by a different OS user, maybe “grid”, and the database carries on as before, typically using the “oracle” OS user. Then the documentation started to push the separation of ownership. Next the installation started to warn you if you used a common user. So now it’s got to the point where people think it is wrong to use a single user as the owner of the GI and database.

I am one of those people that use the “oracle” user as the owner of both the Grid Infrastructure and the database. If you have no separation of duties, I see no point in splitting these between two users. Occasionally I get questions about this in relation to my Vagrant RAC builds, and my response is simple. I don’t work in an environment with separation of duties, so I think splitting the ownership of the GI and database is pointless.

Personally, I think Oracle should remove the warnings from the installer and be more balanced in the documentation. If the poll results of representative of the wider audience, clearly very few people care about separation of duties. It should be an option, not the default assumption.

Cheers

Tim…

DBA and PL/SQL Development Tools (Poll Results Discussed)

I’ve been thinking about my DBA and PL/SQL tool choices recently, so I thought I would go out to Twitter and ask the masses what they are using.

As always, the sample size is small and my followers have an Oracle bias, so you can decide how representative you think these number are…

Here was the first question.

What tool do you do *most* of your Oracle DBA work with?

I expected SQL*Plus and SQLcl to be the winner here, and I was right. A lot of DBAs are still “old school” where administration is concerned. It may be tough for a beginner to use these command line tools, but over time you build up a list of scripts that mean it is much quicker than using GUI tools for most jobs.

SQL Developer had a pretty good showing at nearly 28%. I’m glad people are finding value in the DBA side of SQL Developer. TOAD/other were not doing so well. I know there are a lot of companies out there trying to make money with DBA tools, but maybe this is a tough market for them. Of course there are cross platform tools that may do well with other engines, even though they don’t register so well with the Oracle crowd.

I guess the real surprise was less than 8% using EM Cloud Control. Having said that, I’m considering ditching it myself. I like the performance pages and we use it as a centralized scheduler for backups, but I’m not sure our usage justifies the crazy bloat that is Cloud Control. It would be nice to remove all those agents and clean up! This figure of less than 8% is all the more surprising when you consider it is free (no cost option). Of course total cost of ownership is not just about the price tag…

This was the next question.

What tool do you do most of your PL/SQL development with?

I was expecting SQL Developer to do well here, but I was surprised by how low TOAD was in the list. I’ve worked at a few companies over the years where TOAD was a staple. I guess the consistent improvements to SQL Developer and a price tag of “free” have broken the TOAD strangle hold.

There were a few comments about Allround Aautomations PL/SQL Developer, which I used in one company many years ago. If I could have added an extra line in the poll, I would have put that as an option, because I know it is still popular. There were also mentions of DataGrip and a number of people using VS code with assorted extensions, including Oracle Developer Tools for VS Code.

Sadly, but understandably, SQL*Plus and SQLcl were low on this list. I’m an old timer, so I’ve had jobs where this was the only option. At one job I wrote my own editor in Visual Basic, then rewrote it in Java. Once SQL Developer (known as Raptor at the time) was released I stopped working on my editor…

When you’re doing “proper” PL/SQL development, it’s hard not to use an IDE. They just come with so much cool stuff to make you more productive. These days I tend to mostly write little utilities, or support other coders, so I find myself writing scripts in UltraEdit and compiling them in SQLcl. If I went back to hard core PL/SQL development, I would use an IDE though…

For fun I ended with this question.

SQL Developer and TOAD have a fight to the death. Who wins?

SQL Developer won, but it came out with a detached retina and some broken ribs!

Remember, you are most productive using the tools that suit your working style, but you should always keep your eyes open for better ways of working. Choice is a wonderful thing!

Cheers

Tim…

What architecture are you using for your production Oracle databases? (Poll Results Discussed)

I was having an email discussion with the folks from DBmarlin, and the question came up about the adoption of the multitenant architecture. Were people using the multitenant architecture, or sticking with the non-CDB architecture for now?

Followers of the blog know I threw my hat in with the multitenant architecture from Oracle 12.1.0.2 onward. We use Oracle 19c for everything of value now (there are a couple of dead projects still on 11.2) and all but one of those projects use PDBs. Suspecting I was not the norm here, I asked some questions on Twitter.

As usual I’m going to start with some caveats. The sample size is small. People who interact about tech on social media my not be a diverse sample. I’m going to act like these results are representative of the wider scene, but they may not be.

Here is the first question.

What architecture are you using for your production Oracle databases?

The fact that only 33% were on non-CDB only was a positive sign in my view. The introduction of the multitenant architecture made a lot of people nervous, and it was not without its problems in the early days. Even so, the combined total of only non-CDB and mostly non-CDB is still 50% of respondents. When you consider Oracle 21c makes the multitenant architecture mandatory, and the next long term release is 23c, there is a lot of work for people to do when they make the switch to 23c. The conversion is simple enough. It’s the testing resource that could hurt people.

Having 50% of people using mostly PDBs or all PDBs is a really good sign, and will make life much easier for them when they come to upgrade to the next long term release.

To dig a little deeper I asked this question.

Are you provisioning new production Oracle databases as PDBs?

So just over 65% of people said they are provisioning new Oracle databases as PDBs. That’s very positive, and makes a lot of sense going forward. Why would 35% of people stick with the non-CDB architecture for new databases? Some things I can think of include.

  • They are using an older versions of the database, and don’t have the option of using the multitenant architecture.
  • They want a one-size-fits-all approach to the database, and will convert everything when they are forced to.
  • Vendors don’t support the multitenant architecture. I have one project where I suspect the vendor doesn’t even know the multitenant architecture exists, let alone supports it.
  • Internal development teams haven’t caught up with the database version. From my experience, the only thing that was really affected by our move to PBDs was CRON jobs using OS authentication. We switched to using secure external password stores and everything was fine. I wrote an article on possible solutions to the OS authentication issue here.

If I was not working at my company, I don’t believe they would have been running on 19c with PDBs. I’ve been pushing for many years to improve the attitudes to upgrades and patching. The easy path is to do nothing…

Finally I wondered how many people were purchasing the multitenant option. Remember, from 19c onward you can run up to 3 user-defined PDBs without having to buy the multitenant option.

For those people using PDBs for production Oracle databases, have you bought the Multitenant Option?

At 35%, I’m actually surprised how many people have purchased the multitenant option. I expected it to be a lot lower. Don’t get me wrong, I think the multitenant architecture is fine. I’ve been advocating for people to switch to it and use lone-pdb since it was introduced on Oracle 12.1. I would like to use more than 3 PDBs per 19c instance, but I can’t justify the cost for a feature that I could argue should be free in all editions.

So there you have it. A quick snapshot of what my followers are saying.

Remember, the multitenant architecture is mandatory from Oracle 21c onward, with Oracle 23c being the next long term support release, so you are going to have to get comfortable with this stuff if you want to remain in support long term.

If you want any help getting to grips with the multitenant architecture I have a load of articles and videos.

Cheers

Tim…

Operating Systems for Oracle Databases, Including Windows This Time… (Poll Results Discussed)

Last week I put out a post about operating systems used for running Oracle databases.

Operating Systems for Oracle Databases (Poll Results Discussed)

This was the first question from the previous post.

Which operating system are you using for your Oracle database servers?

Unfortunately I forgot to include Windows. A number of people contacted me about this, asking if I would ask the question again and include Windows this time, so I did. Also, this time I was explicit about production systems, because I suspect some people were answering about their home setup… 🙂

So here we go for the second time…

Which operating system are you using for the majority of your **production** Oracle Databases servers? Not demo kit on your PC at home. A repeat of last week, but remembering to include Windows this time…

We can see Linux is still the clear winner, with UNIX and Windows battling it out for the second place spot. Going back to my statement from the last post, there is no point in purposely making yourself a minority, which would clearly suggest Linux is the place to be. Windows is a slight exception to that, because if your company has no experience on Linux, but a good grounding in Windows administration, it might be a good idea for you to stick with Windows, rather than doing a bad job with Linux. I can’t imagine there are many places with good UNIX skills and no Linux skills, so I’m not going to give the same “get out of jail free card” for that. 🙂

So as I said before, Linux is dominating, so you can see why there is so few posts about Oracle on other platforms these days…

Cheers

Tim…

Operating Systems for Oracle Databases (Poll Results Discussed)

I put out some questions on Twitter a couple of days ago, asking about the operating systems people were using for their Oracle database servers.

As with all these polls, we have to discuss some caveats. Most of the people that follow me are from the Oracle community, so that puts a heavy bias on the outcome. The questions relate to Oracle databases, which also influences the results. Someone may choose one distribution to run Oracle workloads, and a different distribution to run non-Oracle workloads. We also have to remember the sample size is small. Despite this, I’m going to discuss the results as if this were a representative sample of people, even though I accept it may not be. 🙂

This was the first question I asked.

Which operating system are you using for your Oracle Databases servers?

You’ll notice I totally forgot to include Windows, which was a shame because it would have been nice to see that. My main focus was to see how many people were still holding on to the traditional UNIX systems. There was a really strong showing for Linux over UNIX, which was hardly surprising. Every year the dominance of Linux is increasing. A few years back a lot of big companies were still using the traditional UNIX systems, but I guess a lot of people have got sick of spending that sort of cash, and some have probably switched to buying Exadata kit instead. I cant say I’m surprised by this result.

Something I’ve said repeatedly over the years is you should stick to the operating system that is the most popular, as that is the one that is going to get tested the most. There is no point in purposely making yourself a minority IMHO. Having lived through the death of Oracle on Tru64 and HP-UX, I wouldn’t dream of using anything other than Linux now.

This was the next question.

For Linux users, which Linux distro are you using for your Oracle database servers?

Over 65% of the folks picked Oracle Linux, and about 27% picked RHEL. The fact this is a poll about Oracle database servers no doubt added to the skew in this result. Oracle have done a good job of promoting Oracle Linux, and the fact it is free probably helps a lot. I thought Oracle Linux would be the winner here, but I’m not sure I expected it to be by this much. Personally I wouldn’t run on anything other than Oracle Linux by choice. Remember, this is what Exadata uses, and this is what Oracle Cloud uses.

I suspect some of the people that picked “Other” were speaking about non-production systems. Perhaps I should have made it clear I was thinking about production, not test labs…

This was the final question.

For Enterprise Linux users, which version of Oracle Linux and/or RHEL are you using for your Oracle database servers?

It’s good to see that nobody is owning up to OL5/RHEL5. There are still a few things lingering on OL6/RHEL6, but I guess those are probably running old versions of the database.

OL7/RHEL7 is still the most common version, but I guess a lot of this is down to the long lifespan of database servers. I suspect many of these servers were provisioned some time ago. I’m hoping most new deployments are using OL8/RHEL8.

So nothing really that surprising about the outcome of this batch of questions. Pity I didn’t include Windows in the first question. Maybe next time…

Cheers

Tim…