I thought I would refresh my knowledge of creating a standby database and at the same time include some DataGuard Broker configuration which also throws in some changes that came along with 12c
Database Name QUICKIE host server 1 ASM disk
Database Name STAN host server 2 ASM disk
Create a standby database STAN using ACTIVE DUPLICATE from the source database QUICKIE
I posed a note on the Oracle-L Mailing list around pluggable database and why they were not opened automatically by default when the container database was opened. The post is below
I am trying to get my head around the thing about how pluggable databases react after the container database is restarted.
Pre 184.108.40.206 it was necessary to put a startup trigger in to run a ‘alter pluggable database all open;’ command to move them from mounted to open.
When you create a database in 12C it now creates a resource in HAS/CRS , which isn’t a problem
However, when you come to recreate a standby database, probably because it has got such a big lag that it is quicker to recreate than recover the log files, then you will see the following error message :-
On various databases, apparently unrelated we have noticed high activity that seems to be associated with the query below. The quieter the database the more the query stands out.
The following technical detail was put together by a colleague John Evans and have taken it , with his permission, and wrapped some more detail around it as it seemed to be of real value to anybody who might have upgraded an agent to 220.127.116.11
Following an upgrade of the EM agent from 18.104.22.168 (or 22.214.171.124) to 126.96.36.199 after about 90 days of usage we saw a number of agents failing with out of memory errors.
This morning I will pass the 1 million mark for hits on this blog. My first post was written in 2008 and I remember being quite pleased with myself when I reached 5000 hits, I never dreamt of getting 1 million.
The post with the most number of hits is https://jhdba.wordpress.com/2009/05/19/purging-statistics-from-the-sysaux-tablespace/
One that I get still comments on now saying how well it explains what the SQL92_SECURITY parameter actually does
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.