Operating System - OpenVMS
1747984 Members
4515 Online
108756 Solutions
New Discussion

Re: SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

 
SOLVED
Go to solution
Navipa
Frequent Advisor

SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

All,
I have posted the same issue with different thread (below) which was resolved 50% using BOUND Volume set, that is RMU/Restore works, but the IMPORT still fails with Bound Volume with the error below.

http://community.hpe.com/t5/System-Management/Rdb-SQL-IMPORT-fails-with-quot-RMS-W-RTB-8224-byte-record-too/td-p/6838720

As our DB size recently grows larger than 8GB, I have issue with RMU Restore and IMPORT onto a disk size larger than 8GB, because VMS (v6.1) version has the limitation. (RMU Backup and Export works fine with larger size disk). So as per Hein suggestion, I have created BOUND volume set with 2 x 8GB, and with this, the RMU restore works fine, but IMPORT fails with the error below...

IMPORTing table TCCD
%SQL-F-NODATRES, remaining data for this relation will be ignored
%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error extending file SYS$SYSROOT:[RDM$RUJ]TELDB$00B0712182776E40.RUJ;1
-SYSTEM-F-BADPARAM, bad parameter value
%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error extending file SYS$SYSROOT:[RDM$RUJ]TELDB$00B0712182776E40.RUJ;1
-SYSTEM-F-BADPARAM, bad parameter value

IMPORTing table TCOP
%SQL-F-NORELRES, unable to import table TCOP
%RDB-F-SYS_REQUEST, error from system services request
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-FILACCERR, error extending file SYS$SYSROOT:[RDM$RUJ]TELDB$00B0712182776E40.RUJ;1
-SYSTEM-F-BADPARAM, bad parameter value
%RDMS-I-BUGCHKDMP, generating bugcheck dump file SYS$SYSROOT:[SYSMGR]RDSBUGCHK.DMP;27

All the time, the Import fails while importing the table tccd, which is one of the largest table with 3.9GB size. this table detail...
It has 32 different record type and max record length: 77, it is compressed. Data records: 90320653;
bytes used: 3447143990, #of fragments: 1106 (28515 Bytes); and its index (tccd_index) is stored on different uniform area, Index data records: 1911265, and the bytes used: 1830991870 (83%).

The Export file attributes...
TELDB_RDB.RBR;1                    File ID: (11,5,1)  Size: 19131544/19131545            Owner: [SYSTEM]
File organization: Sequential,  Shelved state: Online
File attributes: Allocation: 19131545, Extend: 0, Global buffer count: 0, No version limit
Record format: Variable length, maximum 1024 bytes

Thanks
Navipa

4 REPLIES 4
Bill Hall
Honored Contributor

Re: SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

I'm guessing you ran out of space on your system disk.

RDMS-F-FILACCERR, error extending file SYS$SYSROOT:[RDM$RUJ]TELDB$00B0712182776E40.RUJ;1

Try moving your RUJ to another disk with more free space.  I'm not a DBA, so I'm guessing, but current versions of Rdb support the logical name RDMS$RUJ to direct the location of the RUJ files.

Bill Hall
Mark Hurcombe
Advisor
Solution

Re: SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

You can also use Batch Update in the import script (the default is no batch update), if you're not interested in being able to recover from an error during import, or if your disk space is really tight.

No RUJ's are used if you use batch Update.

Check the SQL manual for the exact syntax, but I'm fairly sure it is just Batch Update.

 

abrsvc
Respected Contributor

Re: SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

I would agree with the other postings here.  Check the size of the RUJ file.  I have seen these files grow VERY large.    Since this iis an import to a "new" database on the larger disk, I would think that the RUJ is not needed.  You can restart the process if you run into problems (such as this one...)  That being the case, the batch option should be faster to complete too.  Without the need for the recovery states to be written, you should be elimination a ton of I/Os and thus time.

Try the batch option first.  But also check to see if you need to redirect the RUJ to another voume set for space reasons in the future.  It may be easier to start with a volume set now for the RUJ even it is not needed now.

 

Dan

Navipa
Frequent Advisor

Re: SQL IMPORT fails while IMPORTing very large table size 3.9GB on to a disk of size larger>8GB

Hi All,
As per the suggestions from Mark Hurcombe and Dan (abrsvc), I have added a BATCH UPDATE argument to IMPORT Statement, it resolved the issue "SQL Import fails while importing large table of size 3.9GB... ".

Thanks to Mark Hurcombe and Dan.

Thanks
Navipa