Most defaults are awesome and one of my consulting mantras is to stick with defaults as much as possible and find and verify good reasons when you want to deviate. The oracle database is pretty amazing out of the box and does most things right. This post however is about two defaults that I find to be very dangerous. Why? Because a DBA might just click through a wizard and select an option that has a lot of negative consequences and cannot be easily fixed.
ASMCA NORMAL REDUNDANCY
When you chose to create a diskgroup with the asmca assistant or wizard, it automatically selects NORMAL as the redundancy level of the diskgroup you are about to create. So what is wrong with that? Several things:
- “Normal” is a very poor choice of words. It implies that this is what everybody should aspire to be or have ignoring the fact that the other two choices might be just as valid. Why not call it 2-way and 3-way mirror?
- Most customers that are not running Exadata will use EXTERNAL and mirror their data on the storage arrays in the SAN. Yes, there are a few who use ASM to mirror LUNs between two arrays but that is more the exception than the norm.
- There is no such thing (yet?) as ALTER DISKGROUP SET REDUNDANCY. The only way to fix an improperly setup diskgroup is to create a new one and move your data. At least in database 12c this move can be done online.
The reason I have time to write this blog post right now is because I am fixing exactly this situation. Another DBA created a diskgroup and forgot to explicitly set EXTERNAL so we ended up with a diskgroup of half the capacity and twice the write activity to the same storage. This was only noticed after trying to migrate the third of four databases and running out of space. And now I am juggling storage and moving lots of data.
I would suggest to just not set a default for this in ASMCA. Ask the user to make an explicit choice between the three options without assuming a default.
DBCA character set
This is a default that is hidden pretty well in the DBCA wizard. You have to switch the tab to character sets to see that by default your new database will be created using the WE8MSWIN1252 a fixed 8-bit character set. This is not the default for everyone though, dbca looks at the language setting of your operating system and guesses that people with western languages will be interested in western characters. I have no idea what dbca would suggest if your OS is set to chinese or arabic but I would hope it is not that one.
I am a big fan of UTF-8. So is Oracle apparently because I could not say it much better than this text from the official documentation from at least 10g:
Oracle Corporation recommends using Unicode for all new system deployments. Migrating legacy systems eventually to Unicode is also recommended. Deploying your systems today in Unicode offers many advantages in usability, compatibility, and extensibility. Oracle Database’s comprehensive support enables you to deploy high-performing systems faster and more easily while utilizing the advantages of Unicode. Even if you do not need to support multilingual data today or have any requirement for Unicode, it is still likely to be the best choice for a new system in the long run and will ultimately save you time and money as well as give you competitive advantages.
- WE8MSWIN1252 does not have all characters. It is fixed to 8 bit and if you want to store anything else in there, you are out of luck. Like the amazing “pile of poo” 💩
- choosing a character set that is limited is a hard choice to make and should not be left to some default
- converting to any other character set can be done but is a pain because some characters have different bytecodes and have to be transformed (converting from 7-bis ASCII to UTF-8 would be easy again)
Dear keepers of DBCA: Please follow through on your documentation and make UTF-8 your default or make this a more prominent decision. I have learned this lesson a long time ago but I am sure there are still DBAs who fall into this trap.