In my last blog about security parameters I mentioned I had found some oddities in the default values for parameters in 188.8.131.52, this is a more in-depth analysis of my findings.
Taking the parameter SEC_RETURN_SERVER_RELEASE_BANNER as an example.
There are 5 parameters that are all prefixed with ‘sec’ in an 11g and 12c database. Actually that is a lie because one is now deprecated in 12c. They are all, as you might guess related to security. This blog is about changes in the default values and some thoughts about whether or not the default value is appropriate or not.
The focus on this post started off in one direction and ended up in another. Originally I had been running a drop user script which had hung and even when I killed the process I could not drop the users as it gave a “ORA-01940: cannot drop a user that is currently connected” – despite the users having left the company months ago and there being no chance of them actually having connected sessions.
Two posts from me on the same day. The other one about Datapatch is about a brand new utility in 12c and is probably new to most people. This post caused mixed reactions when I mentioned it at work last week. Some people laughed at my naivety in not knowing about it, others took the same view as me and were interested to hear about it as it may prove useful one day.
There have been a few changes in the way patches are managed and monitored in 12c and whilst looking at this I found a potential problem that might occur when you clone or copy databases around, or even build them from a template file.
Firstly when you apply a PSU and run an opatch lsinventory command you now see a description of the patch rather than just a patch number – here showing that PSU 1 has been applied. This came in at 184.108.40.206 and in my opinion is really helpful.
I noticed the error message when running lsinventory against a 220.127.116.11 Oracle_Home. As the command worked I didn’t think anymore of it until on the same server against an 18.104.22.168 home I got the same error message.
opatch lsinventory tr: extra operand `y' Try `tr --help' for more information. /app/oracle/product/22.214.171.124/dbhome_1/OPatch/opatch: line 384: [: =: unary operator expected
There is a Mos note which provides a solution – 551584.1
I recently found out that it is possible to change a database link password without dropping and recreating a database link in its entirety.
To be honest I thought this might have existed forever and I had just never come across it but it actually come out in 11GR2
The ALTER DATABASE LINK statement can be used and you do not need to specify the target service either – all you need is to run the following command from the user that owns a pre-existing database link
ALTER DATABASE LINK JOHN connect to USER identified by PASSWORD;
I recently saw the following command in a script that was to be run and thought an error had been made and the power level should have been 5 not 500.
ALTER DISKGROUP DATA REBALANCE POWER 500;
Upon doing some research it was not a mistype but a new method of disk balancing which came in from 126.96.36.199
Previously setting the power limit from 0 to 11 basically caused an additional number of ARBx process to be created to match the power level and these were removed once the rebalance had finished.
Stopping one ASM listener in Flex ASM environment takes down ASM instance
To be honest it was asked 2 years ago in a blog about ASM and rebalancing and someone asked the following question