Thread 1 cannot allocate new log, sequence [message #52540] |
Mon, 29 July 2002 06:57 |
Eddy Confer
Messages: 17 Registered: January 2002
|
Junior Member |
|
|
I am running a script to alter tables. Following is an example for 1 table although I am executing the same command on about 50 tables. Some of the times it works. Other times the system will hang. When I kill the job I see the following entry in the alert log:
Thread 1 advanced to log sequence 73
Current log# 1 seq# 73 mem# 0: D:ORACLE816ORADATAVK816REDO01.LOG
Thread 1 cannot allocate new log, sequence 74
HERE IS THE SAMPLE SQL:
ALTER TABLE RATE ADD(
record_guid RAW(20) NULL,
creatordb_id RAW(4) NULL,
revision_nbr INTEGER NULL,
generation_id INTEGER DEFAULT 0 NULL,
reference_count INTEGER NULL,
sync_session_id INTEGER NULL
);
DROP INDEX XIE1RATE;
/* Code that initializes (seeds) with values the record_guid column of RATE */
BEGIN
dbms_output.put_line('Started updating the table RATE with record_guids. Please wait, this process may take some time.');
END;
/
DECLARE
bnRecGUID raw(20);
CURSOR crRATE IS SELECT record_guid FROM RATE FOR UPDATE OF record_guid NOWAIT;
BEGIN
FOR rate_row in crRATE LOOP
CREATEFINALRECGUID(bnRecGUID);
UPDATE RATE SET record_guid = bnRecGUID WHERE CURRENT OF crRATE;
END LOOP;
END;
/
BEGIN
dbms_output.put_line('Finished updating the table RATE with record_guids.');
dbms_output.put_line(' ');
END;
/
CREATE INDEX RGUID_RATE ON RATE
(
record_guid ASC
);
CREATE INDEX XIE1RATE ON RATE
(
rate_date ASC
);
CREATE INDEX SSID_RATE ON RATE
(
sync_session_id ASC
);
Thread 1 advanced to log sequence 73
Current log# 1 seq# 73 mem# 0: D:ORACLE816ORADATAVK816REDO01.LOG
Thread 1 cannot allocate new log, sequence 74
|
|
|
Re: Thread 1 cannot allocate new log, sequence [message #52542 is a reply to message #52540] |
Mon, 29 July 2002 07:03 |
|
Mahesh Rajendran
Messages: 10708 Registered: March 2002 Location: oracleDocoVille
|
Senior Member Account Moderator |
|
|
1. Verify that the init.ora parameter log_archive_start = true
and other parameters to enable archiving is set properly.
2. It appears that your online logs are too small to handle the
volume of redo being written. I would recommend that you
recreate your online logs with a larger size.
|
|
|