This post runs in parallel with a post I made 5 years ago and which is still the most read one on this blog
It will show how to reduce space taken up in the SYSAUX tablespace by because you have many more AWR snapshots being retained than you think.
Firstly lets take an example database and we can see that we are using 92Gb of space
Performing an rm -rf operation is normally a simple operation albeit risky if you are in the wrong folder. However within ASMCMD there are a couple of bugs associated with it.
Here are two examples and workrounds
Something nice and simple
It is easy to get the current SCN from the database and to map between SCN and timestamp because from 10g onwards there are 2 functions to convert between SCN and TIMESTAMP
Today’s venue was the Metropole Hotel in the centre of Leeds and there was a good attendance, encouraged by a strong agenda.
After introductions, health and safety and UKOUG information it was straight into techie talk with Phil Davies from Oracle doing his normal support update (although he does share duties with Owen Ireland). Invariably I make more notes from this session than most others I hear because of the wealth of information it contains. Snippets I jotted down that are worthy of sharing are :-
Today I am going to mention two articles which I came across in the last few days whilst investigating problems and talk about the background to the problems but also praise the articles. I am sure many of us have run the SQL Tuning advisor from within OEM or using the DBMS_SQLTUNE package from the command line and often it recommends a sql_profile that should be applied, (invariably giving 99.98 perceived benefits). Now I see this as both a good thing and a bad thing.
Just a quick entry to show the use of a command that I had forgotten existed but it seemed to work nicely
Problem – OEM12C agent had been down for a few days on a non-production server and more than the maximum number of files had been created ready to be uploaded.
emctl status agent
It is well known that poor performance on the standby server of a DataGuard pair can affect the performance of the primary database. This post shows an example and how to use the view GV$EVENT_HISTOGRAM to track down an issue.
The databases were 220.127.116.11 on HPUX. I had been seeing alerts from OEM to state that the standby was seeing lag_apply delays when applying redo to standby. Looking at the primary database alert log I could see the entries
Please be aware of the serious bug identified with RMAN duplicate database on the same node with versions 18.104.22.168 and 22.214.171.124
This note gives a brief overview of bug 13498382.
The content was last updated on: 07-FEB-2014
Click here for details of each of the sections below.