Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

SQLUTIl (RESTORE) Is there a size limit?

Tony Boyland
Visitor

SQLUTIl (RESTORE) Is there a size limit?

Hi, Recently my database grew to over 2GB. The SQLUTIL STOREONLINE command then started asking for a 2nd file name. I avoided that by setting "large File" flag on the mounted backup directory, so it now produces only one Database file. Then I use the SQLUTIL RESTORE command on another machine (accessing the remotely mounted backup directory of system above) to update another system each night. However RESTORE refuses to accept only having one stored database file and prompts a second filename.
Does anyone know if there some global parameter that sets the limit of SQLUTIL RESTORE command please?
Thanks,
Tony
7 REPLIES
Eric Antunes
Honored Contributor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hi Tony,

Did you set the "large file" flag in the server where resides the restored database?

The only restriction I read about is the following:

"The maximum length of a pathname is 44 bytes."

PS: Here's the manual in case you don't already have it:

http://docs.hp.com/en/36217-90401/36217-90401.pdf


Best Regards,

Eric Antunes
Each and every day is a good day to learn.
Tony Boyland
Visitor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hello Eric,
Thanks for replying.
I am not sure what you meant by setting the "large file flag" in the server of the restored database.
My 2nd system that I run the "restore" prog on, reads the "stored" database on an exported directory of the main machine, being remotely mounted on the 2nd machine.
However I did think that could be a problem when I changed the main machine mounted dir to "large files", so I un-mounted and re-mounted the remote mounted directory on the 2nd comp in case it needed to re-read the file system. It made no difference.
Yes I read the manual but as you will have seen, it makes no reference to this "feature" except to say that it may prompt for a 2nd file, but doesnâ t say why.
Any more ideas, gratefully received.
Regards,
Tony.
Eric Antunes
Honored Contributor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hi again Tony,

What I meant to say was:

Did you set JFS option largefiles on the restore directory as you did on the mounted backup directory?

Best Regards,

Eric Antunes

Each and every day is a good day to learn.
Tony Boyland
Visitor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hello again Eric,
Ah, now I get your drift, I was being thick!.
Yes it restores directly to the DBE System Catalog & Conf file directory + other dirs for Index's and tables etc, so no I didn't change those because it the "large file" flag isn't set on the main systems database and that is working ok.
However!, I notice the last created Catalog file is 2.048Gb in size, so maybe that becomes a problem when restoring.
I will make a change tomorrow and see if that solves it and let you know how I get on.
Thanks for your input yet again.
Tony.
Eric Antunes
Honored Contributor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hi Tony,

I'll be waiting for your feedback.

Best Regards,

Eric Antunes
Each and every day is a good day to learn.
Tony Boyland
Visitor

Re: SQLUTIl (RESTORE) Is there a size limit?

Hi Eric,
Well it failed again. I set â large filesâ in the restore directory, but it still prompts for a 2nd file name from the backup directory and refuses to accept the same name as before.
I have come to the conclusion (you may not agree) that there is something in the "SQLUTIL RESTORE" function that limits the file size it can read or process in one go.

Anyway, I have a solution in so far as I modified my sh scripts to let the STOREONLINE function create a 2nd backup file and that is accepted by the RESTORE function.

It's just annoying, that by doing it this way, I now have to go through a full testing regime i/c testing what happens if the database shrinks back in size.
Thanks again for your input.
Tony B.
Tony Boyland
Visitor

Re: SQLUTIl (RESTORE) Is there a size limit?

By modifying my nightly job script.
Thanks to Eric Antunes for his helpfull sugestions.
Tony B