File create failed, file size limit reached.

[Gerald Deinzer]

I need to understand the file size limit better, how large a file does RMS allow to be created. We are trying to implement RMAN backup for the Oracle databases and it fails when it trys to create a very large files. I am about to increase the extend quantity on the volume but am unsure if it will be enough, we want to try for 50Gb file if possible. The volume is a bound set of two
raidsets served from the SAN and are 1.7 Tb total. Also, what size is the default file size limit and what determine it?

[Steven Schweda]

The RMS limit is 1TB (2^31-1 blocks).

If Oracle is complaining about less than that,
I doubt that RMS is the problem.

[Jim_McKinney]

See the "FILE6" label at http://www.faqs.org/faqs/dec-faq/vms/part3/ which states

"the volume size and the RMS maximum file size limit is 2**31 * 512 bytes -- one terabyte (1 TB)."

The value is static and can't be changed.

[Steven Schweda]

Oops. 2^31 blocks. The largest block _number_
is 2^31-1.

Bigger than 50GB, anyway.

[Gerald Deinzer]

Thank you, I still would like to know what the file size limit is by default without, setting the extend quantity on the volume or elswhere. Also, are the 'file high-water marking' or disk quota related to the file size.

[Steven Schweda]

The only RMS limit is 1TB.

Normally you can't make a file bigger than
your disk quota. (Otherwise, what good
would a disk quota be?) There is no default
value for disk quota, only what you set.

The extend quantity determines how much a
file may grow in one jump, but it has no
effect on the maximum file size.

Highwater marking also has no effect on the
maximum file size. (It can make the
_creation_ of a large file slower, however.)

[Gerald Deinzer]

If that is the case, why would the file creation fail with a file size limit reached? I doubt the file is greater than 1Tb. Any ideas? I will look at the proceedure the DBA is using but not sure what to look for.

[Steven Schweda]

> why would the file creation fail with a file size limit reached?

Ask the people who wrote the program which
complained. Oracle?

What _is_ your disk quota, by the way? Is it
big enough? (Who owns the new file? What's
_his_ disk quota?)

SHOW QUOTA

[Gerald Deinzer]

Show quota stated that 'disk quotas not enabled on this volume' for system and oracle. System owns all of the directories on the drive in question.

[Duncan Morris]

Gerald, what version of Oracle are you using?

Also, please get the dba to do

RMAN> SHOW ALL;

[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.