ALTER SYSTEM DUMP DATAFILE in 10g

Hi all,
When I refered to the the documentation "Oracle Database SQL Reference 10g Release 2 (10.2)"
to obtain information about the command "ALTER SYSTEM DUMP DATAFILE", I did not see it there.
Is it obsolete?
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_2013.htm#i2053602
Actually, when I tested it, I did not see any trace file generated.
Any guideline is appreciated.

Which OS are you on?
However, ALTER SYSTEM DUMP DATAFILE commands works with 10g, no issues.
Do the following:
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'DUMPFILE';
ALTER SYSDATE DUMP DATAFILE 'FILE.DBF' BLOCK 1;
and now look into your dump you will have file name with prefix as DUMPFILE.
Jaffar

Similar Messages

Trace File Created Upon Execution of "alter system kill session sid, serial# immediate;"

A problem within a third-party application is causing it to create and abandon Oracle sessions. At times three hundred or more abandoned sessions accumulated in the instance. The software company is working on the problem. Oracle's background processes will get rid of those sessions after several hours, but at times there were so many they caused the server to start using paging space. We wrote a SQL*Plus script to identify the abandoned sessions and kill them with command "alter system kill session <sid, serial#> immediate;". We automated the execution of the script a week ago. Today I noticed that in my udump directory an Oracle trace file has been created each time our script kills a session. A single trace file is created regardless of how many sessions are killed. No errors appear in the trace file.
Is the creation of these trace files an indication that problems have occurred or are they there for information only?
Since I know how and why the sessions are being killed, is it safe to ignore the trace files?
Thank you,
Bill

The OS is AIX 5.2. The database server is 10.2.0.2. We are in the processing of upgrading to AIX 7.1 and database server 11.2.0.3.6.
The script does not enable tracing for the SQL*Plus session.
Below is the alert log message from a session killed at 11:22, and the corresponding trace file created at that same time:
From alert_<sid>.log:
Wed Jul 31 11:22:01 2013
Immediate Kill Session#: 1119, Serial#: 59885
Immediate Kill Session: sess: 70000014dc4a7e0 OS pid: 267254
/u02/admin/EXPRESS/udump $ ls -l express_ora_113358.trc
-rw-r----- 1 oracle dba 2276 Jul 31 11:22 express_ora_113358.trc
/u02/admin/EXPRESS/udump $ pg express_ora_113358.trc
Dump file /u02/admin/EXPRESS/udump/express_ora_113358.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0
System name: AIX
Node name: navis
Release: 2
Version: 5
Machine: 0005CD8C4C00
Instance name: EXPRESS
Redo thread mounted by this instance: 1
Oracle process number: 225
Unix process pid: 113358, image: oracleEXPRESS@navis
*** ACTION NAME:() 2013-07-31 11:22:01.181
*** MODULE NAME:(SQL*Plus) 2013-07-31 11:22:01.181
*** SERVICE NAME:(EXPRESS.WORLD) 2013-07-31 11:22:01.181
*** SESSION ID:(1723.61000) 2013-07-31 11:22:01.181
SO: 70000014d44d278, type: 2, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=463, calls cur/top: 0/700000139166298, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 108 0 4
last post received-location: kslpsr
last process to post me: 70000014d36c398 1 6
last post sent: 0 0 24
last post sent-location: ksasnd
last process posted by me: 70000014d36c398 1 6
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 70000014d6aec00
O/S info: user: oracle, term: UNKNOWN, ospid: 267254
OSD pid info: Unix process pid: 267254, image: oracleEXPRESS@navis
Short stack dump:
ksdxfstk+002c<-ksdxcb+04e4<-sspuser+0074<-00004CB0<-nttrd+0120<-nsprecv+0750<-ns
rdr+0114<-nsdo+1714<-nsbrecv+0040<-nioqrc+04a8<-opikndf2+0688<-opitsk+088c<-opii
no+0990<-opiodr+0adc<-opidrv+0474<-sou2o+0090<-opimai_real+01bc<-main+0098<-__st
art+0090
Dump of memory from 0x070000014D2CC3B0 to 0x070000014D2CC5B8
70000014D2CC3B0 00000004 00000000 07000001 39DA8D48 [............9..H]
70000014D2CC3C0 00000010 0003139D 07000001 39166298 [............9.b.]
70000014D2CC3D0 00000003 0003139D 07000001 4C73D508 [............Ls..]
70000014D2CC3E0 0000000B 0003139D 07000001 4DC4A7E0 [............M...]
70000014D2CC3F0 00000004 00031291 00000000 00000000 [................]
70000014D2CC400 00000000 00000000 00000000 00000000 [................]
Repeat 26 times
70000014D2CC5B0 00000000 00000000 [........]
Thanks,
Bill

Syntax to resize datafile in 10g

syntax to resize datafile in 10g

the reason is
in 10g if u want to create tablespace the syntax is
create tablespace table_name datafile 10M;No, actually. The syntax on how to create a tablespace is exactly the same today as it was in 1999. Create tablespace X datafile '/path/filename' size 10M.
It is, however, possible to omit both the path and size clause if you want to use Oracle Managed Files (OMF):
alter system set db_create_file_dest=/path/filename;
create tablespace X;
And then it's possible to add back the size clause if you don't like the default 100M autoextend on which OMF gives you:
create tablespace X datafile size 10M;
or
create tablespace X datafile size 10m autoextend off;
or
create tablespace X datafile size 10m autoextend on next 10m maxsize 400m;
Point is, the syntax for creating a tablespace has many different variations and options, but the basic syntax hasn't changed a bit. The other point is: what has creating a tablespace got to do with what you originally asked about, which was resizing an existing datafile?
to add datafile
alter tablespace table_name add datafile;
it will add datafile with default size and with name
according to its naming convention.Yes, but you are not obliged to let that happen.
alter system set db_create_file_dest=/path/filename;
alter tablespace X add datafile '/different/path/myownfilename' size 37M;
...you switch on OMF and then decide you don't want to use it for one particular file. The presence/existence of OMF is an addition of features if you want to use them. It doesn't take anything away from you and if you want to specify all the parts of the create or alter tablespace clause yourself, you can do so, no sweat -at which point, your syntax will look incredibly like what you would have issued in 8i or 9i days.
Analogy time: yes, today, you can build homes out of steel, concrete, carbon-reinforced composites, whereas in the 16th century you might have used timber, wattle and daub. But a house still has rooms, chimney flues, windows, doors. The house I live in would be recognisable to Shakespeare as a house. And what he lived in would be something I could live in too.
Yeah, well: maybe analogies aren't all they're cracked up to be! But the underlying truth is that Oracle gives you new features in new versions and using them can be highly convenient and useful. Nevertheless, if you understand the underlying principles,the old stuff is still there, still recognisable, still usable.
thats why i am asking for syntax to resize datafile
in 10g ,i had fired above sqls with no errors.Again, I am a little at a loss understanding why the fact that the syntax for creating a tablespace has new options should cause you to think anything weird has happened to the syntax for resizing a datafile.
As others I think have already mentioned: there always were and still remain only three ways of making a tablespace bigger:
add a datafile
resize an existing datafile
switch on autoextension of an existing datafile
alter tablespace X add datafile ['/path/filename'][size 10m];
alter database datafile '/path/filename' resize 54m;
alter database datafile '/path/filename' autoextend on [next Xm] [maxsize Ym];
None of that syntax is different from what you'd use in version 7. Yes, some commands have optional clauses -and some of the clauses which are optional in 10g were compulsory in 7 or 8. But the general syntax is identical, still.

"Alter system set command" in a RAC database!!

Hi, all.
The database is (10.2.0.2.0) 2- node RAC database on 32-bit windows 2003
EE SP1.
I issued the following command on Node 1 database.
--> Alter system set db_block_buffers= xxx sid='rac1';
I was able to see "PE enqueue" in top 5 wait event section from an AWR report.
In addition, I was able to find "PZ99","PZ98" process dump file in BDUMP.
Soon later, I could find CKPT and DBWR hung.
Is there anyone who experienced this issue?
Thanks and Regards.
Message was edited by:
user507290

10.2.0.2 has some bug which is fixed 10.2.0.3
You check sequence cache. If it has less value, increase it to 10000.
select CACHE_SIZE from dba_sequences where SEQUENCE_OWNER='SYS' and SEQUENCE_NAME='AUDSES$';
SQL> alter sequence sys.audses$ cache 10000;
Ashok

Question on alter system set cluster_database = true

11.2.0.2.0 windows 2008
doing a restore to a development RAC I noticed the following. I took the database out of cluster mode on one instance
alter system set cluster_database=false scope=spfile sid='PRD1';
shutdown, start up, do the restore, all good, I go to set cluster_Database=true but had issue instance would only start on one node, I reviewed my notes and found problem was when I set cluster_Database back to true I had typed
alter system set cluster_database=true scope=spfile sid='*';
instead of
alter system set cluster_database=true scope=spfile sid='PRD1';
So issue fixed.
I retested and confirmed '*' wont take. Ive seen many examples of '*' working online and I am sure I have used '*' many times so had just typed it off my head. Anyone explain? probably quotes or something.

Any chance there are multiple lines for cluster_database in the spfile ?I had thought maybe this, but confirmed no, it was a fresh build anyway that I was restoring to.
>
- Dump the spfile to a pfile ... edit ... recreate the spfile on all nodes.
>
Im not sure what this will achieve? the spfile is shared on the ASM.
>
As the cluster_database=true is a parameter to enable the RAC configuration. As you typed sid='*' it will try to enable the cluster_database parameter in all the instances(nodes) as it is RAC.
In your case as you did on a single node by specifiying the sid name it will work as it will look only for that sid and enable that particular node.
>
I find this hard to read but I think this misinterprets as well.
Thanks for the contribution. I think Ive found the solution
the asterisk doesnt apparently mean actually "all instances", from here
http://www.comp.dit.ie/btierney/oracle11gdoc/rac.111/b28254/admin.htm#BCEFICEE
and
"Setting SPFILE Parameter Values for Oracle Real Application Clusters"
-- this is a good example of what happened to me
>
*.OPEN_CURSORS=500
prod1.OPEN_CURSORS=1000
Note:
The value before the dot in an SPFILE entry identifies the instance to which the particular parameter value belongs. When an asterisk precedes the dot, the value is applied to all instances that do not have a subsequent, individual value listed in the SPFILE.
For the instance with the Oracle system identifier (SID) prod1, the OPEN_CURSORS parameter is set to 1000 even though it has a database-wide setting of 500. Parameter file entries that have the asterisk (*) wildcard character only affect the instances without an instance-specific entry. This gives you control over parameter settings for instance prod1. These two types of settings can appear in any order in the parameter file.
If another DBA runs the following statement, then Oracle updates the setting on all instances except the instance with SID prod1:
ALTER SYSTEM SET OPEN_CURSORS=1500 sid='*' SCOPE=MEMORY;
>
so when I was on node 1 and ran it for *, I was setting it for all the nodes except the node I was on which holds true from what Ive seen. I'll remember that one.

Alter system set events Question

Version 10202 on AIX
sql> alter system set events '4030 trace name heapdump level 536870917; name errorstack level 3';
Questions about this statement..
what this command is doing, i guess creating tracefile for event 4030...& the location of trace file would be the current direcotry?
& how to setup same kind of event trace for other events, any tips....& what to check in tracefile for problem?

The values for level I have record are 1, 2, 3, 8, and 32 so I am guessing the number shown is the address of a specific heap to be dumped. The address of a heap would potentially change with a change in the shared pool storage parameters. Where did you get the address value?
The dump should go to the user background dump destination and not the current directory.
PS - if you have metalink look at document: #218105.1 Introduction to ORACLE Diagnostic EVENTS
HTH -- Mark D Powell --
Message was edited by: MDP add PS to Metalink Doc
mpowel01

ALTER SYSTEM SET SGA_TARGET

Hi,
in 10g R2 should I stop/start database when I change sGA_TARGET :
ALTER SYSTEM SET SGA_TARGET=value [SCOPE={SPFILE|MEMORY|BOTH}]
Thank you.

user522961 wrote:
OK.
When I query V$PARAMETER I have the OLD value for SGA_TARGET. It is normal because the value in V$PARAMETER comes from starting and spfile. How can I be sur that now oRACLE uses the new value for SGA_TARGET effectively ?
Thanks again.Not sure I understand your question. If you set SGA_TARGET with SCOPE=MEMORY or BOTH, it should be in effect immediately.
SQL> alter system set sga_target=253M scope=both;
System altered.
SQL> select value bytes, value/1048576 MB from v$parameter where name = 'sga_target';
BYTES              MB
268435456         256
SQL> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 256M
SQL> alter system set sga_target=257M scope=both;
System altered.
SQL> select value bytes, value/1048576 MB from v$parameter where name = 'sga_target';
BYTES              MB
272629760         260
SQL> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 260M
SQL>

Alter system kill session in RAC

Hi,
After identifying all inactive jdbc sessions or blocking sessions from gv$session or gv$lock respectively, should alter system kill session executed in both instances of RAC?, Can't we execute like alter system kill session ' inst_id,sid,serial#' from a single instance to kill all the session of RAC instances?
So, above problem answered in 11g as:
Alter system kill session ‘SID, serial#, @instance_id’;
Eg: ALTER SYSTEM KILL SESSION ‘115,9779,@1';
So, In our environment, most of the databases are in 10gR1 or 10g R2. Is there any patch for 10g Where instance_id can be recognized by alter system kill session?
Thanks,
Sunil.

Hi Dan,
Not sure what you mean by "instance specific kill session capability".
To be clear, I'm speaking of a new feature, introduced in 11gR1, that provides for an optional third parameter to 'alter system kill session', which allows you to kill a session on a remote instance, in a RAC environment.
Documentation is here:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_2013.htm#i2065117
-Mark

RMAN ALert Log Message: ALTER SYSTEM ARCHIVE LOG

Created a new Database on Oracle 10.2.0.4 and now seeing "ALTER SYSTEM ARCHIVE LOG" in the Alert Log only when the online RMAN backup runs:
Wed Aug 26 21:52:03 2009
ALTER SYSTEM ARCHIVE LOG
Wed Aug 26 21:52:03 2009
Thread 1 advanced to log sequence 35 (LGWR switch)
Current log# 2 seq# 35 mem# 0: /u01/app/oracle/oradata/aatest/redo02.log
Current log# 2 seq# 35 mem# 1: /u03/oradata/aatest/redo02a.log
Wed Aug 26 21:53:37 2009
ALTER SYSTEM ARCHIVE LOG
Wed Aug 26 21:53:37 2009
Thread 1 advanced to log sequence 36 (LGWR switch)
Current log# 3 seq# 36 mem# 0: /u01/app/oracle/oradata/aatest/redo03.log
Current log# 3 seq# 36 mem# 1: /u03/oradata/aatest/redo03a.log
Wed Aug 26 21:53:40 2009
Starting control autobackup
Control autobackup written to DISK device
handle '/u03/exports/backups/aatest/c-2538018370-20090826-00'
I am not issuing a log swiitch command. The RMAN commands I am running are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/exports/backups/aatest/%F';
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u03/exports/backups/aatest/%d_%U';
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-2';
I do not see this message on any other 10.2.0.4 instances. Has anyone seen this and if so why is this showing in the log?
Thank you,
Curt Swartzlander

There's no problem with log switch. Please refer to documentation for more information on syntax "PLUS ARCHIVELOG"
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/bkup003.htm#sthref377
Adding BACKUP ... PLUS ARCHIVELOG causes RMAN to do the following:
*1. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command.*
*2. Runs BACKUP ARCHIVELOG ALL. Note that if backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device.*
*3. Backs up the rest of the files specified in BACKUP command.*
*4. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command.*
*5. Backs up any remaining archived logs generated during the backup.*
This guarantees that datafile backups taken during the command are recoverable to a consistent state.

Alter database create datafile as

Hi
T1-)shutdown immediate;
T2-)Take full backup
T3-)startup;
T4-)move the objects in tablespace test1 to some other tablespace
T5-)drop tablespace test1;
T6-)create tablespace test1
datafile 'C:\oraclexe\oradata\XE\test1.dbf' reuse;
T7-)alter system switch logfile;
In some other server;
startup nomount;
restore the backupset which was taken at T2.
restore controlfile at T7.
startup mount;
alter database create datafile 'C:\oraclexe\oradata\XE\test1.dbf' as 'C:\oraclexe\oradata\XE\test1.dbf';
ALTER DATABASE RECOVER automatic database until cancel using backup controlfile;
Recovery performed succefully.
What I wanna ask is;
Since First I issue:
"alter database create datafile as ...."
The contents of this datafile should be deleted with this statement.
Why oracle doesnt give error in recovery, during appliying the statement at T4 ?
I have already deleted the contents of the datafile, how come oracle move the objects?
I hope I am clear

Hi,
although it is beyound my imagination what kind of real world scenario you are trying to simulate with your test, I can tell you why no error gets returned:
You create a new tablespace t1 after you dropped the old one. That gets stored in the current controlfile. The previous backup of the datafile of the old tablespace that incidentally has the same name is now useless for the new tablespace.
You then restore that controlfile and create the datafile manually as it looked after you created the new tablespace (empty) and then recover that. RMAN does that (without complaining even about the uselessness of your doing). If you look into that tablespace, you will see that it is empty as it was after you created it - unless you have put any objects into it after the second creation of that tablespace t1.
Kind regards
Uwe
http://uhesse.wordpress.com

ALTER SYSTEM SET _awr_flush_threshold_metrics=TRUE SCOPE=MEMORY;

Hi,
our DB in 10g R2 on Win 2003 server has suddenly restarted with this message in alertlog :
ALTER SYSTEM SET awrflush_threshold_metrics=TRUE SCOPE=MEMORY;
I looked for this parameter in oracle documentation, I did not find.
1-what is this parameter for ?
2-How can I see which user connection has altered this parameter ?
Thanks.

user522961 wrote:
Hi,
our DB in 10g R2 on Win 2003 server has suddenly restarted with this message in alertlog :
ALTER SYSTEM SET awrflush_threshold_metrics=TRUE SCOPE=MEMORY;
I looked for this parameter in oracle documentation, I did not find.
1-what is this parameter for ?
2-How can I see which user connection has altered this parameter ?
Thanks.I don't think that you should be worried about it as its an undocumented parameter.
http://www.orafaq.com/parms/parm113.htm
Without Auditing, its not possible who changed it(if he really did)?
HTH
Aman....

Alter system with scope=both

Hi,
I am trying to enable automatic log archiving at instance start up. I have tried to use the "scope=both" parameter to change both the current session and have it also update the spfile. I tried using this command:
alter system archive log start to 'C:\oracle\ora92\database\dbname\archive' SCOPE=spfile;
However it give me an error at the keyword SCOPE saying:
ERROR at line 1:
ORA-00933: SQL command not properly ended
Any ideas on how to do this or do I have to export the spfile to a pfile, make the changes there and then create the pfile from the spfile ?
Thanks in advance,
Ned

If I change to archivelog mode in Mount state using alter database archivelog;
Will that also automatically set those parameter. Take 10g for example?
By default the destination of archive log files are stored in flash recovery area without any additional configuration. In that case i also assume now that those parameter such as log_archive_start=true will also be automatically be set when the DB is set to archivelog mode (in reference of 10g).
Correct me if i'm wrong...

ALTER SYSTEM SET processes=1000 generates ORA-00064: object is too large to

Hi All
I'm using Oracle Release 10.2.0.1.0.
When performing:
=============
ALTER SYSTEM SET processes=10000 SCOPE=SPFILE;
We can't start the 10g DB: ORA-00064: object is too large to allocate on this O/S (1,5282400)
When reducing the size to 150 there is no problem starting the db. I can not start it. ORA-00064: object is too large to allocate on this O/S (1,5282400)
I refered to ORA-00064: object is too large to allocate on this O/S :::Plz Help Me
But I can not resolve this problem.
Please help me.
thiensu

Not sure, because i haven't got ORA-00064 yet.
ORA-00064: object is too large to allocate on this O/S num, num
Cause: The initialization parameter DB_BLOCK_SIZE is set to a value that calls for more contiguous space than can be allocated on the operating system being used.
Action: Reduce the value of DB_BLOCK_SIZE so that the requested contiguous space is within the capacity of the operating system.
http://www.pitt.edu/~hoffman/oradoc/server.804/a58312/newch2a1.htm
Regards
Girish Sharma

Alter system switch logfile

Hi all,
As Oracle says, this command "lets you explicitly force Oracle Database to begin writing to a new redo log file group". But, how does Oracle Database 10g choose which redo log file group will be used next?
I faced a situation where it follows a strange pattern:
SQL> alter system switch logfile;
System altered.
SQL> select f.GROUP#, f.MEMBER, l.BYTES/1024/1024 MB, l.STATUS from v$logfile f, v$log l where f.group# = l.group#;
    GROUP# MEMBER                                   MB STATUS
         1 /redologs/MYDB/redoMYDB01.log             800 INACTIVE
         2 /redologs/MYDB/redoMYDB02.log             800 INACTIVE
         3 /redologs/MYDB/redoMYDB03.log             800 INACTIVE
         4 /redologs/MYDB/redoMYDB04.log             800 ACTIVE
         5 /redologs/MYDB/redoMYDB05.log             800 ACTIVE
         6 /oradata/dbf1/MYDB/redoMYDB06.log         800 INACTIVE
         7 /oradata/dbf1/MYDB/redoMYDB07.log         800 INACTIVE
         8 /oradata/dbf1/MYDB/redoMYDB08.log         800 INACTIVE
         9 /oradata/dbf1/MYDB/redoMYDB09.log         800 INACTIVE
        10 /oradata/dbf1/MYDB/redoMYDB10.log         800 INACTIVE
        11 /oradata/dbf1/MYDB/redoMYDB11.log         800 INACTIVE
        12 /oradata/dbf1/MYDB/redoMYDB12.log         800 INACTIVE
        13 /oradata/dbf1/MYDB/redoMYDB13.log         800 INACTIVE
        14 /oradata/dbf1/MYDB/redoMYDB14.log         800 INACTIVE
        15 /oradata/dbf1/MYDB/redoMYDB15.log         800 INACTIVE
        16 /oradata/dbf1/MYDB/redoMYDB16.log         800 CURRENT
16 rows selected.
SQL> alter system switch logfile;
System altered.
SQL> select f.GROUP#, f.MEMBER, l.BYTES/1024/1024 MB, l.STATUS from v$logfile f, v$log l where f.group# = l.group#;
    GROUP# MEMBER                                   MB STATUS
         1 /redologs/MYDB/redoMYDB01.log             800 INACTIVE
         2 /redologs/MYDB/redoMYDB02.log             800 INACTIVE
         3 /redologs/MYDB/redoMYDB03.log             800 INACTIVE
         4 /redologs/MYDB/redoMYDB04.log             800 ACTIVE
         5 /redologs/MYDB/redoMYDB05.log             800 ACTIVE
         6 /oradata/dbf1/MYDB/redoMYDB06.log         800 CURRENT
         7 /oradata/dbf1/MYDB/redoMYDB07.log         800 INACTIVE
         8 /oradata/dbf1/MYDB/redoMYDB08.log         800 INACTIVE
         9 /oradata/dbf1/MYDB/redoMYDB09.log         800 INACTIVE
        10 /oradata/dbf1/MYDB/redoMYDB10.log         800 INACTIVE
        11 /oradata/dbf1/MYDB/redoMYDB11.log         800 INACTIVE
        12 /oradata/dbf1/MYDB/redoMYDB12.log         800 INACTIVE
        13 /oradata/dbf1/MYDB/redoMYDB13.log         800 INACTIVE
        14 /oradata/dbf1/MYDB/redoMYDB14.log         800 INACTIVE
        15 /oradata/dbf1/MYDB/redoMYDB15.log         800 INACTIVE
        16 /oradata/dbf1/MYDB/redoMYDB16.log         800 ACTIVE
16 rows selected.
Thanks!

Oracle doesn't use the GROUP# to identify the "next" redo log.
It switched from Group#16 to Group#6. This would happen if, in the past, Group#6 was added to the database when Group#16 was the CURRENT redolog. At that time, the next SWITCH from Group#16 would have caused it to switch from Group#16 to the "newest" UNUSED group -- Group#6. Thereafter, Oracle persists with the behaviour of switching from Group#16 to Group#6.
Hemant K Chitale

Remove alter system checkpoint from Backup script

We are seeing high response time when we run alter system checkpoint and when we run "BEGIN BACKUP". Can we remove that from the script currently it's something like:
alter system checkpoint
alter system archive current
begin backup
Also would suspend/resume help if we have it after "begin backup" in response time?
Edited by: user628400 on Mar 26, 2009 5:06 PM

Hi;
It says;
"SQL-induced checkpoints are heavyweight. This means that Oracle records the checkpoint in a control file shared by all the redo threads. Oracle also updates the datafile headers. SQL-induced checkpoints move the checkpoint position to the point that corresponded to the end of the log when the statement was initiated. These checkpoints can adversely affect performance, because the additional writes to the datafiles increase system overhead."
According to my experiences, manually checkpointing has never been a quick operation.
How long it takes to finish checkpoint?

ALTER SYSTEM DUMP DATAFILE in 10g

Similar Messages

Maybe you are looking for