File create failed, file size limit reached.

[Hein van den Heuvel · Accepted solution]

Hello Gerald,

Welcome to the HP ITRC OpenVMS Forum.


>> We are trying to implement RMAN backup for the Oracle databases

What kind of rman command?
"backup as compressed backupset... " ?

>> it fails when it trys to create a very large files.

What EXACT error message / sub-message?
Any details in some (alert) log?

>> I am about to increase the extend quantity on the volume but am unsure if it will be enough

A larger extent may speed up the process but should not have a functional effect.
The best performance comes from a good INITIAL allocation.

The process/device max is 65K, but I would
expect Oracle to use an explicit extent size over-ruling any default.

Check the exact RMAN command you use for options to set an initial and/or extend size.

>> we want to try for 50Gb file if possible

That's a large file, but not excessive. Should be no problem.
Was is up to any particular size when it broke?


>> The volume is a bound set of two
raidsets served from the SAN and are 1.7 Tb total

Now that _is_ big, and a relatively unique situation. You may be in untested area. Why not stick to individual volumes less and 1TB?

If such volume is suppose to hold only very large (GB sized) files, then you may want to re-create it with a larger CLUSTERSIZE (1024? 2048?). This will make the allocation/extent process easier: fewer chunks to deal with.

Hth,
Hein.

[Gerald Deinzer]

Oracle8i Enterprise Edition Release 8.1.7.3.0 and the RMAN> SHOW ALL; command does not work.
In order to increase the cluster size will I need to reinitailize the raidset and alter the chunksize also. If so, now is a goot time to do it.

[Hein van den Heuvel]

>> In order to increase the cluster size will I need to reinitailize the raidset and alter the chunksize also.

Nah, not really.

I wouldn't worry about a relation between clustersize and chunck size.

Actually, I personally always do worry about it, but decided it is too hard, and too low impact a problem to deal with.
The chucksize impact has to do with the IO size and start address distribution. This _rarely_ has any correspondance with the cluster size, other then that a first block ina file is always cluster aligned, and therefor _could_ be chunk aligned.
"don't worry be happy".

Just an INIT at VMS level will do the trick just fine.

So no error message huh?
It just 'stopped'?
I'm guessing something must have happened which made you declare 'failure'. :-).
Please elaborate.

Cheers,
Hein.

[Gerald Deinzer]

The specific error message is at the end of the attached log file.
The specific RMAN commands are:

This is the portion that is failing:

replace script CRS_LVL0_ARCH {

#create script CRS_LVL0_ARCH {

ALLOCATE CHANNEL D0 TYPE DISK;

ALLOCATE CHANNEL D1 TYPE DISK;



BACKUP

INCREMENTAL LEVEL=0

FORMAT 'BKUP:[DATAFILES]DATA_%U.DFB'

TAG='CRS_LVL0'

FILESPERSET=10

DATABASE;



# Backup Archived Logs

SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';



BACKUP

ARCHIVELOG ALL DELETE INPUT

FORMAT 'BKUP:[ARCHIVELOGS]ARCH_%U.ALB'

FILESPERSET=20;



BACKUP

FORMAT 'BKUP:[CONTROLFILES]CTRL_%U.CFB'

CURRENT CONTROLFILE;



RELEASE CHANNEL D0;

RELEASE CHANNEL D1;

}

[Peter Zeiszler]

"The volume is a bound set of two
raidsets served from the SAN and are 1.7 Tb total"
if the Oracle database is one huge file then the file is limited to the amount of space on One of the bound volumes. The volume that the file originated is where it stays. That was a limitation I found long time ago. I don't remember the version of VMS that was evident and I don't know if that is a limitation still in affect.

So imagine you have 2 disks bound together. You create some HUGE files. If ALL of the files started on one disk then you are really only using one of the 2 disks.

Why not just have the SAN present the volumes as one big disk? Let the hardware perform your raid instead of using bound volumes.

If this problem is not around anymore that would be nice to know.

[Gerald Deinzer]

I attempted to create a raidset of all the disks but ran into the 1 Tb limitation for any storageset on the HSG80. Would this be a situation where I should use the concatset option of the HSG80?

[Hein van den Heuvel]

I suspect you are running into an Oracle limitation, not an OpenVMS one.

So Ask ORACLE first and foremost.

Isn't there a limitation of 4 million db_block_size pages in an Oracle managed .dbf file?
So for a 4KB pagesize that would would be 16GB, and 32GB for a typical 8KB page size?
Is that where it broke? 32GB.


I don't expect that you ran out of space.
The way VMS deals with volume sets is to allocate any new file on the relative volume with most space. So if that is wrong, then you are probably hosed no matter what.

It is also my understanding that if the original volume runs out, then an EXTENTION FILE HEADER is created on the next-emptiest volume and the file can grow there.
Unfortunately I do not have the time, not resources (DecRAM or LDdriver!), just now to try that.

Hein,

ORA-27039 create file failed, file size limit reached

Cause: An attempt was made to create a file that exceeds the process' file size limit, additional information indicates which function encountered the error.

Action: Raise the file size limit.

[Gerald Deinzer]

Well it looks like you're onto something, we checked and there was an Oracle patch (2147442) which apparently wasn't installed on this system and it addresses some sort of 4Gb limitation on 8i (8.1.7...). We need to schedule for this patch, so not a quick fix for now. Thanks so much for all the help, much appreciated!

[Gerald Deinzer]

The solution is to install Oracle patch 2147442 on Oracle for OpenVMS 8.1.7.3.