Ensuring Nonstop SQL Safety: A Practical Guide to Backing Up and Restoring SQL/MX with PAK2/UNPAK2

Ensuring Nonstop SQL Safety

We are all familiar with HPE Nonstop SQL/MX Database, one of the world’s robust and scalable distributed relational database systems, renowned for its fault tolerance and high availability. With its fast OLTP capabilities, customers use SQL/MX in various sectors, including finance, stock exchanges, telecommunications, and mission-critical applications. This highlights the need to maintain a safe database for recovery in the event of system hardware or software failures, application outages, or other similar incidents.

This article serves as a guide to backup and restore the SQL/MX database using the PAK2/UNPAK2 utility.

TMF and BR2

The TMF (Transaction Management Facility) protects SQL/MX databases by managing transactions and allowing recovery through dump files and audit trails. Customers should follow established guidelines and implement scheduled daily database dumps as part of their routine, enabling quick recovery in the event of unexpected data loss or system failure. TMF Online Dump serves as a primary mechanism for safeguarding NonStop SQL data, offering the advantage of requiring no database downtime.

Another important mechanism to protect your SQL/MX databases is to use the Backup/Restore 2 (BR2) product. It supports backing up and restoring both SQL/MX and OSS entities.

When TMF can provide online backup support, what is the need for BR2? The answer is that an SQL/MX object recovered by TMF may or may not be consistent with the current metadata description of the object. It means that if the schema of the SQL/MX table is changed after the TMF dump is taken, then the dump cannot be used to recover the SQL/MX data that was backed up. In other words, TMF Online DUMP does not take a backup of the DDL structure of the SQL/MX table but only the table data.

BR2 ensures full backup of the DDL structure and the data in the SQL/MX tables. While TMF DUMP is online, BR2 is mostly offline.

BRCOM and PAK2/UNPAK2

BRCOM, which is part of the BR2 product, is an interface on the guardian side that allows customers to issue the backup or restore commands. It mainly supports backing up data to tapes mounted on the Nonstop systems. It supports both SQL/MX and OSS objects.

PAK2/UNPAK2 is an OSS utility to archive OSS or SQL/MX objects to disk. It does not require expertise in the tape system to perform backup and restore of SQL/MX objects.

PAK2/UNPAK2 uses BR2 to perform the backup and restore operation.

BACKUP and RESTORE JOB OPTIONS

Job options are settings specific to the backup or restore command. During backup, various backup job options can be specified in the PAK2 command. During restore, one or more restore job options can be specified in the UNPAK2 command.

BACKUP/RESTORE JOB OPTIONS

BACKUP-ONLY JOB OPTIONS

RESTORE-ONLY JOB OPTIONS

  • LISTALL ON/OFF/DETAIL
  • PARTONLY ON/OFF
  • SQLDATA ON/OFF
  • LOBDATA ON/OFF
  • INDEXES EXCLUDED/INCLUDED
  • CONSTRAINTS EXCLUDED/INCLUDED
  • OPEN ON/OFF
  • LOCATION <LOCMAP>
  • KEEPGFN ON/OFF
  • KEEP ON/OFF
  • SHOWDDL ON/OFF
  • SHOWDDLLOC
    <OSSLOC>
  • OBEYDDL ON/OFF
  • LISTONLY ON/OFF

*The default value of the job option is in bold.

CREATING SQL/MX OBJECTS

You can create SQL/MX objects via MXCI (SQL/MX Conversational Interface). Refer SQL/MX User Guide to create SQL/MX objects.

SQL/MX OBJECT HIERARCHY

For each object type, the keyword to be used in the PAK2/UNPAK2 command is given in the brackets.

gravic3

Although Indexes and LOB tables reside at the schema level and use three-part names, they are logically considered components of their associated table objects.

Schema Level Dependent Objects

  • Views
  • Stored Procedures in Java (SPJs)
  • Synonyms
  • External Sequence Generators

Table Level Dependent Objects

  • Triggers
  • Referential Integrity Constraints (RI constraints)

INSTALLATION

Install the T1355 product version supported for your Nonstop system. The files pak2 and unpak2are installed in the OSS location
/usr/tandem/pak2_unpak2/T1355<VERSION>_<DATE>_<SPR>, like
/usr/tandem/pak2_unpak2/T1355L01_22NOV24_AAF.
The location can be added to the system PATH variable for easy access to the pak2/unpak2executables.

export PATH=$PATH:/usr/tandem/pak2_unpak2/T1355L01_22NOV24_AAF

If PATH variable cannot be altered, create a symbolic link to these two files in /usr/bin or copy the files to the location /usr/bin, if needed.

Important Note

  • PAK2 and UNPAK2 command syntax with special characters like (, ),/<,” must be enclosed in single quotes at the OSS prompt of  the Nonstop System.
pak2 testpak, 'MX ((SCH "CATALOG1".SCHEMA1) WHERE (EOF < 12288))', LISTALL ON
  • Alternatively, each special character can be escaped with a backslash character ‘\’ or enclosed within a single quote.
pak2 testpak, MX '(' '('SCH \"CATALOG1\".SCHEMA2')' WHERE \
(EOF '>' 0 \) ')', LISTALL ON
  • A backslash character ‘\’ can be used as a line break to split the commands into multiple lines. It is not needed in the last line of the command in the OSS shell prompt. If line breaks are used to split the command, then each special character in the command must be escaped with a backslash character ‘\’ or enclosed within a single quote.
pak2 testpak, MX '(' '('SCH \"CATALOG1\".SCHEMA2')' WHERE \ '('EOF '>' 0 ')' ')', LISTALL ON
  • The PAK2/UNPAK2 or BR2 command syntax is not case OSS path names are case sensitive. For example, pak2 and unpak2 are OSS executables, and hence they are case sensitive.
pak2 testpak, mx '(' '('sch \"CATALOG1\".schema2')' where '('eof '>' 0 ')' ')', listall ON.
  • It is not recommended to provide the OSS location of the guardian file (like /G/DATA1/testpak) as the archive name. Naming issues may arise when the archive size exceeds a certain limit and needs to be split into multiple files, as guardian file names have a length limit of 8 characters only.

In this article, the PAK2/UNPAK2 command syntax keywords are written in upper case, and the user-defined values are written in lower case for uniformity.

PAK2

It is a utility used to compress SQL/MX objects into archive files. It can also be described as it is used to back up SQL/MX objects as OSS files. Backup job options can be specified in the PAK2 command.

Authorisation

  • Only a Super user (255,255) or an object owner can backup the schema and its subordinate objects.
  • Only during catalog-level backup, any user is allowed to begin the backup, but the objects owned by the logged-in user are only backed up.

CATALOG Backup

Backs up the catalog and all underlying objects referred to as its subordinate objects as shown in the objects’ hierarchy.

pak2 /home/pakfiles/mycat_pak, MX CATALOG mycat, LISTALL ON

mycat_pak is the archive file here. It can be specified with an absolute path or a relative path based on the current directory from which the command is executed.

  • If there are any catalog names with delimited names, they must be included within the double
pak2 /home/pakfiles/mycat_pak, 'MX (CATALOG "myDelimited_cat")', LISTALL ON
  • To allow backup of SQL/MX objects even when the SQL/MX files are in open state (except for exclusive access), the OPEN ON job option is used.
pak2 /home/pakfiles/mycat_pak, MX CATALOG mycat, LISTALL ON, OPEN ON

SCHEMA Backup

Backs up the schema and all its subordinate objects, along with schema-level dependent objects.

pak2 /home/pakfiles/mysch_pak, MX SCHEMA mycat.mysch, LISTALL ON

TABLE Backup

Backs up the table and its subordinate objects, along with table-level dependent objects.

pak2 /home/pakfiles/mytab_pak, MX TABLE mycat.mysch.mytab, \ LISTALL ON

‘\’ is used as line break here.

  • To exclude the indexes while backing up the table, specify both INDEXES EXCLUDED and CONSTRAINTS EXCLUDED job options together.
pak2 /home/pakfiles/mytab_pak, MX TABLE mycat.mysch.mytab, \ LISTALL ON, CONSTRAINTS EXCLUDED, INDEXES EXCLUDED
  • To exclude table data in the table during backup, specify the SQLDATA OFF job It also excludes LOB table data if the table has any LOB columns in it.
pak2 /home/pakfiles/mytab_pak, MX TBL mycat.mysch.mytab, LISTALL ON, SQLDATA OFF
  • To exclude only LOB table data during table backup, specify the LOBDATA OFF job
pak2 /home/pakfiles/mytab_pak, MX TBL mycat.mysch.my_lob_tab, LISTALL ON, LOBDATA OFF

LOBDATA ON and SQLDATA OFF job options cannot be specified together. SQLDATA OFF implicitly sets LOBDATA to OFF.

LOBTABLE Backup

Backup one or more LOB tables of the LOB columns in a SQL/MX table. If table mycat.mysch.my_lob_tab has LOB columns l1 and l2, two LOB tables l1_tab and l2_tab are associated with the table my_lob_tab. The LOB tables can be backed up individually, whereas the LOB table partitions cannot be backed up individually.

pak2 /home/pakfiles/mylobtab1_pak, MX LOBTABLE mycat.mysch.l1_tab, LISTALL ON
pak2 /home/pakfiles/mylobtab2_pak, 'MX (LOBTBL mycat.mysch.l1_tab, LOBTABLE mycat.mysch.l2_tab)', LISTALL ON

LOBDATA OFF and SQLDATA OFF job options are not applicable, as the LOB table backup is mainly intended to backup LOB table data.

INDEX Backup

Backs up the SQL/MX index on a table. INDEXES EXCLUDED and CONSTRAINTS EXCLUDED cannot be specified as the INDEX backup is intended to take a backup of indexes.

pak2 /home/pakfiles/ind_pak, MX INDEX mycat.mysch.ind1, LISTALL ON
pak2 /home/pakfiles/ind_pak, 'MX (INDEX mycat.mysch.ind1, IND mycat.mysch.ind2)', LISTALL ON

TABLE PARTITION Backup

Backs up the table partition of the SQL/MX table individually. It is allowed to specify more than one partition of a table in the same command.

Must specify job options:

    • PARTONLY ON
    • CONSTRAINTS EXCLUDED
    • INDEXES EXCLUDED
pak2 /home/pakfiles/part1_pak, 'MX TPART mycat.mysch.mytab PARTITION (part1)’, LISTALL ON, PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED
pak2 /home/pakfiles/part_pak, 'MX (TPART mycat.mysch.mytab PARTITION (part1, part2, part3))', LISTALL ON, PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED

INDEX PARTITION Backup

Backs up the index partitions of the SQL/MX table. More than one index partition can be specified in the command. PARTONLY ON job option must be specified.

pak2 /home/pakfiles/ipart1_pak, 'MX IPART mycat.mysch.ind1 PARTITION (ipart1), LISTALL ON, PARTONLY ON
pak2 /home/pakfiles/ipart_pak, 'MX (IPART mycat.mysch.ind1 PARTITION (part1, part2, part3))', LISTALL ON, PARTONLY ON

Multiple Objects Backup

Backs up different types of objects in the same command. If the same object is repeated more than once, backup is taken only once. For example, if a catalog c1 and the table c1.s1.t1 in the same catalog are specified in a single backup command, the table is backed up only once.

pak2 /home/pakfiles/multi_pak, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5))', PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON

Backup with Filtering

The WHERE clause can be used with any of the above PAK2 commands to filter out certain objects from getting backed up. SQL/MX supported filters are:

FILTER Valid for Object Examples
OWNER SCHEMA OWNER = SQL.USER1
OWNER = SQL.*
OWNER = 20,30
OWNER = 20,*
CREATIONTIME TABLE CREATIONTIME AFTER 02 JUL 2025

08:25:30

LASTOPENTIME TABLE/INDEX PARTITIONS LASTOPENTIME BEFORE JUL 2 2025
MODTIME TABLE/INDEX PARTITIONS MODTIME > 1 JAN 2024
REDEFINITIONTIME TABLE and INDEX REDEFINITIONTIME < 31 JUN 2025
TABLE ALL TABLE
EOF TABLE/INDEX PARTITIONS EOF > 2000
EOF <= 30000
EOF = 0
EOF <> 0
pak2 /home/pakfiles/filter_pak1, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5)) WHERE (CREATIONTIME BEFORE 1 JUL 2025), PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON
pak2 /home/pakfiles/filter_pak2, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5)) WHERE (EOF <> 0)', PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON

UNPAK2

One can restore a SQL/MX object from the same level of backup or a higher level of backup using UNPAK2. For example, one can use a catalog backup and perform a table restore but the reverse is not recommended.

You can restore the same SQL/MX object that was backed up or specify a different target object using the TARGET/ TGT clause in the unpak2 command i.e., you can backup table c1.s1.t1 and restore the data to the same table c1.s1.t1 or a different target schema c2.s2 or a different table in the same target schema c1.s1.t2.

Authorisation

  • Only Super user (255,255) or an object owner can restore the schema and its subordinate objects.
  • Only in catalog-level restore, any user is allowed to begin the restore, but the objects owned by the logged-in user are only restored.

CATALOG Restore

Restores the catalog and all its underlying objects referred to as its subordinate objects, as shown in the objects’ hierarchy. You can restore the backed-up catalog, called the source catalog, into a different catalog with a different name, called the target catalog.

unpak2 /home/pakfiles/mycat_pak, 'MX CATALOG mycat, LISTALL ON
unpak2 /home/pakfiles/mycat_pak, 'MX (CATALOG mycat, TGT CAT tgtcat)', LISTALL ON
  • To restore to a different system, the LOCATION job option must be used if the data volumes used by the SQL/MX objects in the source system are different from those of the target system. It is necessary to map all the volumes that are used by the objects in the backup for a successful restore of all the objects.
unpak2 /home/pakfiles/mycat_pak, 'MX (CATALOG mycat, TGT CAT tgtcat), LISTALL ON, LOCATION (\SYS1.$DATA5 to \SYS2.$SAS4,\SYS1.$DATA2 to \SYS2.$SAS3, \SYS1.$DATA7 to \SYS2.$SAS8)'
  • To restore both schema-level and table-level dependent objects, SHOWDDL ON, SHOWDDLLOC <oss-location> and OBEYDDL ON must be used together. The location specified in the SHOWDDLLOC job option must exist.
unpak2 /home/pakfiles/mycat_pak, 'MX (CATALOG mycat, TGT CAT tgtcat), LISTALL ON, SHOWDDL ON, SHOWDDLLOC /home/ddl_loc, OBEYDDL ON'

The SHOWDDDL files are generated in the OSS location /home/ddl_loc for views, SPJs, RIs, Triggers, etc. If the OBEYDDL job option is not specified, then SHOWDDL files must be manually obeyed by the user to restore the dependent objects.

  • During restore, the LISTONLY ON job option is used to list the objects in the backup without being restored.
unpak2 /home/pakfilesk/mycat_pak, MX CATALOG mycat, LISTONLY ON

SCHEMA Restore

Restores the schema and all its subordinate objects. Schema can be restored to a different target catalog (with the same name as the source schema) or a different target schema (with a different name than the source schema).

unpak2 /home/pakfiles/mysch_pak, MX SCHEMA mycat.mysch, LISTALL ON
unpak2 /home/pakfiles/mysch_pak, 'MX (SCHEMA mycat.mysch, TGT SCH tgtcat.tgtsch )', LISTALL ON
  • The schema can be restored from the catalog-level or schema-level backup. The target can be specified one level higher than the source. Here, the schema is restored as mysch.
unpak2 /home/pakfiles/mycat_pak, 'MX (SCHEMA mycat.mysch, TGT CAT tgtcat)', LISTALL ON
  • To restore both schema-level and table-level dependent objects, SHOWDDL ON, SHOWDDLLOC <oss-location>, and OBEYDDL ON must be used together.
unpak2 /home/pakfiles/mycat_pak, 'MX (CATALOG mycat, TGT CAT tgtcat, LISTALL ON, SHOWDDL ON, SHOWDDLLOC /home/ddl_loc, OBEYDDL ON'

TABLE Restore

Restores the table and its subordinate objects. The catalog-level or schema-level backup can be used to restore. The table can be restored to a different target schema or a table name.

unpak2 /home/pakfiles/mytab_pak, MX TABLE mycat.mysch.mytab, LISTALL ON
  • To restore the table-level dependent objects, SHOWDDL ON, SHOWDDLLOC <oss-location>, and OBEYDDL ON must be used together.
unpak2 /home/pakfiles/mycat_pak, 'MX (TABLE mycat.mysch.mytab, TGT SCH tgtcat.tgtsch ), LISTALL ON, SHOWDDL ON, SHOWDDLLOC /home/ddl_loc, OBEYDDL ON'
  • To skip restoring the already existing objects in the target schema, KEEP ON job option can be used. Only non-existent objects are restored if this option is specified. It is not applicable for dependent objects.
unpak2 /home/pakfiles/mycat_pak, 'MX (TABLE mycat.mysch.mytab, TGT TBL tgtcat.tgtsch.tgttab), LISTALL ON, KEEP ON'

If the table tgtcat.tgtsch.tgttab already exists, then the table is skipped to be restored with a warning. This job option can also be used in the schema-level restore.

  • To only restore DDL and skip the data in the partitions of the table or index, the SQLDATA OFF option can be used.
unpak2 /home/pakfiles/mytab_pak, 'MX (TABLE mycat.mysch.mytab, TGT TBL tgtcat.tgtsch.tgttab)', LISTALL ON, SQLDATA OFF
  • To only restore DDL and skip the data in the partitions of the LOB tables only, LOBDATA OFF can be used.
unpak2 /home/pakfiles/mytab_pak, 'MX (TABLE mycat.mysch.mytab, TGT TBL tgtcat.tgtsch.tgttab)', LISTALL ON, LOBDATA OFF

Points to remember:

    • SQLDATA OFF and LOBDATA ON cannot be used together.
    • Backups taken with SQLDATA/LOBDATA OFF cannot be used to restore with SQLDATA/LOBDATA ON.
  • During restore, an SQL/MX target table is restored with its partitions’ Guardian File Names (GFN) the same as the source table. If the source table also exists in the same system, then the table restore operation will fail since the same GFNs exist in the To allow restore of the target table with different GFNs than the source table, the KEEPGFN OFF job option can be used. This is applicable in catalog-level, schema-level, and table-level restores.
unpak2 /home/pakfiles/mytab_pak, 'MX(TABLE mycat.mysch.mytab, TGT TBL tgtcat.tgtsch.tgttab)', LISTALL ON, KEEPGFN OFF

LOBTABLE Restore

Restore one or more LOB tables of the LOB columns in an SQL/MX table individually. LOBDATA OFF is not applicable as LOB table restores are meant for restoring the LOB table data.

Points to remember:

    • The TARGET or TGT option must be specified.
    • Only TABLE can be specified as the TARGET option
    • Target table must exist with the LOB Tables with the same name or a different name.
    • Source and target tables must match in their DDL structure.
unpak2 /home/pakfiles/mylobtab1_pak, 'MX (LOBTBL mycat.mysch.l1_tab, TGT TBL tgtcat.tgtsch.tgttab)', LISTALL ON

INDEX Restore

Restores the SQL/MX index on a target table. INDEXES EXCLUDED job option should not be used in the INDEX restore. The index can be restored only to the target table of the same name as the source. Only TABLE can be specified as the TARGET option.

unpak2 /home/pakfiles/mycat_pak, 'MX (IND mycat.mysch.ind1, TGT TABLE tgtcat.tgtsch.mytab)', LISTALL ON

TABLE PARTITION Restore

Restores one or more table partitions of the SQL/MX table. More than one table partition can be specified in the restore command. Only TABLE can be specified as the TARGET option.

Must specify job options:

    • PARTONLY ON
    • CONSTRAINTS EXCLUDED
    • INDEXES EXCLUDED

The source and target tables should match in the DDL structure. The partition restore must be exercised with caution. The DDL locks on the targe table would be removed on successful restore of all the partitions of the table.

unpak2 /home/pakfiles/part1_pak, 'MX TPART mycat.mysch.mytab PARTITION (part1)', LISTALL ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, PARTONLY ON
unpak2 /home/pakfiles/part_pak, 'MX (TPART mycat.mysch.mytab PARTITION (part1, part2, part3), TGT TABLE tgtcat.tgtsch.tgttab)', LISTALL ON, PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED

INDEX PARTITION Restore

Restores the index partitions of the SQL/MX table’s index. Only INDEX can be specified as the TARGET option. More than one partition can be specified in the restore command. PARTONLY ON job option must be specified.

unpak2 /home/pakfiles/ipart1_pak, 'MX IPART mycat.mysch.ind1 PARTITION (ipart1)', LISTALL ON, PARTONLY ON
unpak2 /home/pakfiles/ipart_pak, MX '(IPART mycat.mysch.ind1 PARTITION (part1, part2, part3), TGT INDEX tgtcat.tgtsch.ind1)', LISTALL ON, PARTONLY ON

Multiple Objects Restore

Restore different types of objects in the same command. If the same object is repeated more than once, the restore is done only once. For example, a catalog c1 is specified, and the table c1.s1.t1 in the same catalog is specified in the single restore command, the table is restored only once.

unpak2 /home/pakfiles/multi_pak, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5))', PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON

Restore with Filtering

The WHERE clause can be used with any of the above UNPAK2 commands to filter out certain objects from getting backed up.

unpak2 /home/pakfiles/filter_pak1, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5)) WHERE (CREATIONTIME BEFORE 1 JUL 2025)', PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON
unpak2 /home/pakfiles/filter_pak2, 'MX (CATALOG cat2, TABLE cat1.sch1.tab1, TPART cat1.sch2.tab2 PARTITION (TPART5)) WHERE (EOF<> 0)', PARTONLY ON, INDEXES EXCLUDED, CONSTRAINTS EXCLUDED, LISTALL ON

PAK2-UNPAK2 SPECIFIC OPTIONS

With -i option and @infile

If the list of objects is large, the command can exceed the maximum limit of characters in the command line. The infile option can be used at such times. The infile must have the same commands starting from the MX keyword. It is not necessary to use the single quote enclosure to escape special characters.

pak2 -i /home/pakfiles/mytab_pak_in, @bkpinfile

bkpinfile content

MX (TBL mycat.mysch.mytab), SQLDATA ON, LISTALL ON;
unpak2 -i /home/pakfiles/mytab_pak_in, @restinfile

restinfile content:

MX (TABLE mycat.mysch.mytab, TARGET SCHEMA tgtcat.tgtsch), 
LOCATION ( \SYS1.$DATA5 to \SYS2.$DBS01 , \SYS1.$DATA2 to \SYS2.$DBS02 , \SYS1.$DATA7 to \SYS2.$SAS2) ,
 OBEYDDL ON, SHOWDDLLOC /home/ddl_loc/, 
SHOWDDL ON,
SQLDATA ON,
KEEPGFN OFF,
 LISTALL ON;

 

Note for infile content

    • It is not necessary to use the single quote to enclose the command with special characters.
    • The command should terminate with a semicolon.
    • The mandatory or minimum expected job option is LISTALL ON or WAIT ON.

PAK2-ONLY OPTIONS

split

Helps to create a multifile archive with input as {nnn| nnnK | nnnM} where the size of the archive can be specified in bytes or kilobytes or megabytes. Each file can grow up to a max of 2,144,722,944 bytes or up to what is specified in the split option. When the first file fills up, a second one is created. The names of the additional files are formed by appending a sequence number to the name of the first file.

pak2 -split 3562435534 testpak, MX CAT mycat, LISTALL ON 
pak2 -split 356K testpak, MX CAT mycat, LISTALL ON
pak2 -split 946M testpak, MX SCH mycat.mysch, LISTALL ON

The files are named as testpak, testpak.1 and testpak.2 and so on.

nocompress

Backs up the given SQL/MX object without compressing the archive file.

pak2 -nocompress testpak, MX CAT mycat, LISTALL ON

 

PAK2/UNPAK2 details are documented in the Open System Services (OSS) Guide and BR2 details are present in the Backup Restore 2 User Guide.

Backing up and restoring SQL/MX databases is essential for maintaining data integrity and ensuring business continuity. I believe this article can serve as a handy guide for users and DB administrators to use the PAK2/UNPAK2 tool effectively for safeguarding critical data through disk-based backups. By taking regular backups and archives, organizations can minimize downtime, recover quickly from failures, and maintain a secure and reliable database environment.

Author

  • Revathi S

    Revathi S is a Senior Specialist in the HPE Nonstop SQL/MX division with 15 years of hands-on experience in enterprise database systems. She has played a key role in developing various features for critical components, including Catalog Manager, SQL/MX utilities, and backup/restore tools. With deep knowledge of database internals, she brings both practical insights and architectural clarity to data safety strategies. Her experience also spans Database-as-a-Service (DBaaS) initiatives like SQL/MX DBS and WebDBS. Revathi recently earned her master’s degree in Machine Learning and Artificial Intelligence and is now actively exploring the convergence of AI and database technologies through research and innovation.

    View all posts