I've had some brief corruption caused by sunspots (actually, it was a proof of concept DR test, the corrupt blocks were caused by NOLOGGING operations) and I decided to repair blocks by using BLOCKRECOVER CORRUPTION LIST. The database version is 11.2. Everything worked as planned. I then went to check the RMAN manual for 11G and BLOCKRECOVER command is no longer there, it is replaced by the new options to RECOVER commands. However, BLOCKRECOVER still works as a charm. So does "BACKUP VALIDATE" which was superseded by the VALIDATE command. Oh well, the old dog is learning the new terminology for the old tricks. VALIDATE command in 11G produces a beautiful report:
RMAN> validate database;
Starting validate at 2012-08-17 10:43:38
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00007 name=/data/oracle/data/O11/test_lob.dbf
input datafile file number=00001 name=/data/oracle/data/O11/system01.dbf
input datafile file number=00002 name=/data/oracle/data/O11/sysaux01.dbf
input datafile file number=00006 name=/data/oracle/data/O11/test_tbs.dbf
input datafile file number=00003 name=/data/oracle/data/O11/undotbs01.dbf
input datafile file number=00005 name=/data/oracle/data/O11/example01.dbf
input datafile file number=00004 name=/data/oracle/data/O11/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:03:15
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 246114 327720 2715101 File Name: /data/oracle/data/O11/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 62724 Index 0 13756 Other 0 5086
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2 OK 0 257793 327682 2715099 File Name: /data/oracle/data/O11/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 19854 Index 0 18063 Other 0 31970
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
3 OK 0 13977 65536 2715101 File Name: /data/oracle/data/O11/undotbs01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0 Index 0 0 Other 0 51559
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4 OK 0 30623 32795 2624870 File Name: /data/oracle/data/O11/users01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 523 Index 0 100 Other 0 1522
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
5 OK 0 54947 65537 2675272 File Name: /data/oracle/data/O11/example01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 6600
Index 0 1148
Other 0 2841
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
6 OK 0 261993 262144 1900091 File Name: /data/oracle/data/O11/test_tbs.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 18
Index 0 0 Other 0 133
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7 OK 0 37402 393216 1900091 File Name: /data/oracle/data/O11/test_lob.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0 Index 0 95
Other 0 355719
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE OK 0 2 Control File OK 0 600 Finished validate at 2012-08-17 10:46:55
Mladen Gogala wrote,on my timestamp of 18/08/2012 1:00 AM:
> I've had some brief corruption caused by sunspots (actually, it was a
> proof of concept DR test, the corrupt blocks were caused by NOLOGGING
> operations) and I decided to repair blocks by using BLOCKRECOVER
> CORRUPTION LIST. The database version is 11.2. Everything worked as
> planned. I then went to check the RMAN manual for 11G and BLOCKRECOVER
> command is no longer there, it is replaced by the new options to RECOVER
> commands. However, BLOCKRECOVER still works as a charm.
Yeah, quite a few diffs. We need to add these to our local SydneyOracleMeetup prezzie on rman. I got a feeling 11gr2 is going to become a lot more relevant over here.
> So does "BACKUP
> VALIDATE" which was superseded by the VALIDATE command. Oh well, the old
> dog is learning the new terminology for the old tricks. VALIDATE command
> in 11G produces a beautiful report:
On Sat, 18 Aug 2012 21:57:44 +1000, Noons wrote:
> Yeah, quite a few diffs. We need to add these to our local
> SydneyOracleMeetup prezzie on rman. I got a feeling 11gr2 is going to
> become a lot more relevant over here.
Everything would be so much easier if only DBA 1.0 guys like me would stop reading manuals.
AFAIK validate database came out in 11.1 ... as long as the "old
commands" work like they used to not a huge fan of minor syntax
changes ( enhancements ) when they work exactly the same as the old
ones.
I guess this one might be a minor exception since it is more clear to
people who do not really know the old command does not really backup
the database that this is only "checking things" ...
On Sat, 18 Aug 2012 17:34:25 -0700, John Hurley wrote:
> AFAIK validate database came out in 11.1 ..
I have never used 11.1 in production or on a serious development machine so I have never had a need to back it up. 11.2 is here to stay, at least for a while: http://tinyurl.com/9uh2kde My guess is that 11.2.0.4 will probably be unleashed onto the world in late September/early October, just like the previous patch version. That will be the terminal version that will get PSU patches every 3 months and will remain the most pervasive version at least until 2015 when companies will start launching the exploratory phase of the upgrade projects again.
The old wisdom of upgrading to the terminal version still applies. That's what happened to 11.1, that's what will happen to 12c.
Essentially, 12.0 will be for the serious geeks like you and me, to install on their home desktops. 12.1 will be for adventurers and for the first exploration projects. 12.2.0.2 will start the "upgrade madness". I don't expect to see it before 2015.
11G was a serious rewrite. A lot of things were changed: latches, ASM, RAC, Oracle*Net, SGA handling, caching, SQL baselines, a lot of really ground breaking stuff. True to the old lore, the versions with the even numbers are stable versions which are just an improvement over the previous version, the one with the odd number, like 11. I expect to see some stability, but not in the early versions.
Mladen Gogala wrote,on my timestamp of 19/08/2012 3:12 PM:
> Essentially, 12.0 will be for the serious geeks like you and me, to
> install on their home desktops. 12.1 will be for adventurers and for the
> first exploration projects. 12.2.0.2 will start the "upgrade madness". I
> don't expect to see it before 2015.
Agreed. My next upgrade cycle is going to be around that date, so I'm hoping by then 11.2.0.3 will be out - I don't trust the even-ended releases of Oracle... ;-)
> ground breaking stuff. True to the old lore, the versions with the even
> numbers are stable versions which are just an improvement over the
> previous version, the one with the odd number, like 11. I expect to see
> some stability, but not in the early versions.
Oh goody! That means 12c will be the end of the line for me!
Plenty of time, then.
# My guess is that 11.2.0.4 will probably be unleashed onto the world
in late September/early October, just like the previous patch version.
Sounds early to me but hard to guess ... I was at an 11.2 upgrade
seminar last thurday ( from Oracle ). Only 470 pages of relevant
information in the guide ??
On Aug 19, 8:25 pm, Noons <wizofo...@yahoo.com.au> wrote:
> Agreed. My next upgrade cycle is going to be around that date, so I'm hoping by
> then 11.2.0.3 will be out - I don't trust the even-ended releases of Oracle... ;-)
On Aug 19, 5:58 pm, Noons <wizofo...@gmail.com> wrote:
> On Aug 19, 8:25 pm, Noons <wizofo...@yahoo.com.au> wrote:
> > Agreed. My next upgrade cycle is going to be around that date, so I'm hoping by
> > then 11.2.0.3 will be out - I don't trust the even-ended releases of Oracle... ;-)
On Mon, 20 Aug 2012 08:47:33 -0700, joel garry wrote:
> On Aug 19, 5:58 pm, Noons <wizofo...@gmail.com> wrote:
>> On Aug 19, 8:25 pm, Noons <wizofo...@yahoo.com.au> wrote:
>> > Agreed. My next upgrade cycle is going to be around that date, so
>> > I'm hoping by then 11.2.0.3 will be out - I don't trust the
>> > even-ended releases of Oracle... ;-)
# True to the old lore, the versions with the even numbers are stable
versions which are just an improvement over the previous version, the
one with the odd number, like 11. I expect to see some stability, but
not in the early versions.
Lost me completely ... please explain some more.
8 was buggy as hell for a long time ... first stuff out in 10 was
pretty ugly.
On Tuesday, August 21, 2012 9:25:14 PM UTC-4, John Hurley wrote:
> Mladen:
> # True to the old lore, the versions with the even numbers are stable
> versions which are just an improvement over the previous version, the
> one with the odd number, like 11. I expect to see some stability, but
> not in the early versions.
> Lost me completely ... please explain some more.
> 8 was buggy as hell for a long time ... first stuff out in 10 was
> pretty ugly.
> For us 11.1 was pretty darn bullet proof ...
I have also been using 11.1.0.7.1 for a while which is very stable.
One thing however never worked was baselines or something like where Oracle will change query plan only when it guarentees that there will be 3 times improvement in performance.. I found that sysaux tablespace kept increasing and I had to disbale this feature. I hope it has been fixed in 11.2. but the place where I work, I will bot be able to upgrade to 11.2 until 2015...
