Unloads a database into a specified directory.
dbunload [ options ] [ directory ]
Option | Description |
---|---|
@data |
Reads options from the specified environment variable or configuration file. To protect information in the configuration file, use the File Hiding utility (dbfhide) to encode the contents of the configuration file. |
-ac "keyword=value; ..." |
Connects to an existing database and reloads the data directly into it, combining the operations of unloading a database and reloading the results into an existing database. For example, you could create a new database using the dbinit utility, and then reload it using this option. This method is useful when you want to change initialization options. The following command loads a copy of the data.db database into an existing database file named backup.db: dbunload -c "UID=DBA;PWD=passwd;DBF=data.db" -ac "UID=DBA;PWD=passwd;DBF=backup.db" If the new database must have the same file name as the original database, then use the DBN connection parameter to give each database a unique temporary name. The following command loads a copy of the old database into a new database that has the same file name data.db. dbunload -c "UID=DBA;PWD=passwd;DBN=old;DBF=\master\data.db" -ac "UID=DBA;PWD=passwd;DBN=new;DBF=\backup\data.db" If the original database was created using version 9 or earlier of SQL Anywhere and the new database is not already running, you must provide a database server name in the -ac option. For example: dbunload -c "UID=DBA;PWD=passwd;DBF=data.db" -ac "UID=DBA;PWD=passwd;DBF=newdata.db;Server=newserver" If you specify this option, then no interim copy of the data is created on disk, so do not specify an unload directory in the command. This behavior provides greater security for your data. If you specify this option, then passwords are automatically unloaded; you do not have to specify the -up option. |
-ae |
Use this option when rebuilding a database (for example, the -ac, -an, -ar options) to specify that the unload operation proceed even if errors are encountered. When -ae is specified, dbunload executes all statements in the reload.sql script file. If any statements result in an error, then they are skipped and logged in the unprocessed.sql script file. They are also displayed in the command line output (unless the -q option is specified). After attempting to rebuild a database that encountered errors, review and fix the errors and rebuild the database from scratch (recommended), or fix them in the unprocessed.sql script file and apply them to the unfinished database. This option is not for use when rebuilding online databases (for example, -ao or -aob options). |
-an database |
Combines the operations of unloading a database, creating a new database, and loading the data using this option. The options specified when you created the source database are used to create the new database. However, you can change the initialization options as necessary by specifying other supported dbunload options (such as -ap to change the page size or -et to enable table encryption). For example, the following command creates a new database file named copy.db and copies the schema and data of data.db into it: dbunload -c "UID=DBA;PWD=passwd;DBF=data.db" -an copy.db If you use this option, no interim copy of the data is created on disk, so you do not specify an unload directory in the command. This provides greater security for your data. When the new database is created, the dbspace file names have an R appended to the file extension to prevent file name conflicts if the dbspace file for the new database is created in the same directory as the dbspace for the original database. For example, if an unloaded database has a dbspace called library in the file library.db, then the library dbspace for the new database is library.dbR. The file specified by -an is relative to the database server. If you specify this option, then passwords are automatically unloaded; you do not have to specify the -up option. |
-ao database-name |
Performs a full backup and an incremental backup to produce a rebuilt database to which you can apply log files from the production database. To use the -ao option, the following conditions must be met:
If the conditions below cannot be met, then consider rebuilding the database using dbunload -aob:
When using the -c option with the -ao option, the connection string is for the production database and is used to back up the initial database before the rebuild and to create an incremental transaction log backup, which is applied to the rebuild. Database encryption settings cannot be changed during an online rebuild. Settings from the original database are automatically preserved. If the database is using strong encryption, then use the -ek or -ep dbunload option to provide the current encryption key. The rebuilt database cannot be restarted unless a copy of the production database transaction log is located in the same directory as the database file. The rebuilt database's transaction log path is in the same directory as the database file, regardless of any relative or absolute path in the original production database. |
-aob |
Creates a rebuild database to which you can apply transaction logs from the production database. If there are no regular times when there are no outstanding transactions by any user on the production server, or if multiple backups to the production server and transaction log renames on the production server are not acceptable, then perform a full backup with a transaction log rename, ensuring that there are no transactions in progress during the log rename. Then you can do an online rebuild from that backup by using dbunload -aob, where the connection string is to the backup database, rather than the production database. You can then apply the transaction log from the production database after the backup. The rebuilt database's transaction log path is in the same directory as the database file, regardless of any relative or absolute path in the original production database. Database encryption settings cannot be changed during an online rebuild. Settings from the original database are automatically preserved. If the database is using strong encryption, then use the -ek or -ep dbunload option to provide the current encryption key. Note Use the -ao option to rebuild a database whenever possible because it includes an initial full backup, rebuild, and one or more iterations of applying the transaction log. There are fewer steps required both before
and after the rebuild when using the -ao option as compared with using the -aob option.
|
-aot seconds | Specifies the maximum time for an incremental backup of the production database and the rebuilt database. This option is ignored unless -ao is also used. If the incremental backup and apply time is greater than the value
specified, then another incremental backup and apply is performed. To stop the incremental backup and apply at any time, press Q and dbunload stops after applying the backup. Note Specifying -aot
0 is not valid. Specifying a value for seconds that is less than one minute can cause indefinite looping (until the Q key is pressed), and also can result in hundreds
of transaction log renames on the production database.
|
-ap size [ k ] |
Sets the page size of the new database. For example, the following command unloads a database, old.db, into a new database, new.db, and changes the page size to 8k: dbunload -c "UID=DBA;PWD=passwd;DBN=old;DBF=old.db" -an new.db -ap 8k This option is ignored unless -an or -ar is also used. The page size for a database can be (in bytes) 2048 (deprecated), 4096, 8192, 16384, or 32768, with the default being the page size of the original database. Use k to specify units of kilobytes (for example, -ap 4k). You must specify either -an or -ar with this option. If there are already databases running on the database server, the server's page size (set with the -gp option) must be large enough to handle the new page size. |
-ar [ directory ] |
Creates a new database with the same settings as the old database, reloads it, and replaces the old database. However, you can change the initialization options as necessary by specifying other supported dbunload options (such as -ap to change the page size or -et to enable table encryption). If you use this option, there can be no other connections to the database, and the database connection must be local, not over a network. If you specify an optional directory, the transaction log offsets are reset for replication purposes, and the transaction log from the old database is moved to the specified directory. The named directory should be the directory that holds the old transaction logs used by the Message Agent. The transaction log management is handled only if the database is used in replication: if there is no SQL Remote publisher, then the old transaction log is not needed and is deleted instead of being copied to the specified directory. When the new database is created, the dbspace file names have an R appended to the file name to prevent file name conflicts if the dbspace file for the new database is created in the same directory as the dbspace for the original database. For example, if an unloaded database has a dbspace called library in the file library.db, then the library dbspace for the new database is library.dbR. If you are rebuilding an encrypted database, the encryption key for the original and new databases must be the same. Using the -ar option resets the database truncation points to zero. If you specify this option, then passwords are automatically unloaded; you do not have to specify the -up option. |
-bp |
Groups CREATE INDEX and LOAD TABLE statements inside BEGIN PARALLEL WORK statements in the reload.sql file. Statements inside a BEGIN PARALLEL WORK statement execute in parallel. |
-c "keyword=value; ..." |
Specifies the connection parameters for the source database. For example, the following statement unloads the sample database, connecting as user ID DBA with password sql. The data is unloaded into the c:\unload directory. dbunload -c "DBF=%SQLANYSAMP17%\demo.db;UID=DBA;PWD=sql" c:\unload |
-cm { sql | dbinit } |
Displays in the command prompt the CREATE DATABASE or dbinit command to create a database that is the same as the one being unloaded. If -an is also specified, the command that is displayed is the command to create the new database.
When displaying the CREATE DATABASE statement or dbinit command, asterisks appear for the DBA user ID, DBA password, and encryption key (if there is one). The creation command or statement is not displayed if you unload a database that was created with a version 10 or earlier database server. |
-cp | Compresses the table data output files by appending the COMPRESSED keyword to the UNLOAD TABLE statements it executes. This option has no effect when specified with -an or -ar. |
-d | Does not generate any of the database definition statements (CREATE TABLE, CREATE INDEX, and so on); reload.sql contains statements to reload the data only. |
-dc |
Forces all computed columns in the database to be recalculated. By default, computed column values are not recalculated. When the -dc option is specified, a new section is added to the reload.sql script to recompute computed columns. Statements of the following form are added. ALTER TABLE "owner"."table-name" ALTER "computed-column" SET COMPUTE (compute-expression); If your tables contain context-sensitive computed values, such as CURRENT DATE, use the ALTER TABLE statement to recalculate computed column values instead of using the -dc option. |
-dt directory | Specifies the temporary directory used during the rebuild. The directory must exist and must have enough space available for the production database and transaction log file. There also must be enough space for the newly created database if the temporary directory and the rebuilt database are in the same disk partition. This option is ignored unless the -ao option is specified. If this option is not specified, the default location for SQL Anywhere temporary files is used. |
-e table, ... |
Excludes the specified tables from the reload.sql file. Table names are always case insensitive, even in case sensitive databases. A reload.sql file created with the -e option should not be used to rebuild a database because the file will not include all the database tables. If a table has foreign keys referring to it, the database cannot be rebuilt without the contents of the table. Only use the -e option with the -d option to unload data for all tables except those identified by -e. |
-ea algorithm |
Specifies the encoding algorithm used for database or table encryption (-et). Specify -ea simple for simple obfuscation (do not specify -ek or -ep). Simple obfuscation is intended only to keep data hidden in the event of casual direct access of the database file, to make it more difficult for someone to decipher the data in your database using a disk utility to look at the file. For greater security, specify AES or AES256 for 128-bit or 256-bit strong encryption, respectively. Specify AES_FIPS or AES256_FIPS for 128-bit or 256-bit FIPS-certified encryption, respectively. For strong encryption, you must also specify the -ek or -ep option. To create a database that is not encrypted, specify -ea none, or do not include the -ea option (and do not specify -e, -et, -ep, or -ek). If you do not specify the -ea option, the default behavior is as follows:
Algorithm names are case insensitive. |
-ek key |
Specifies an encryption key in the dbunload command for the new database created if you unload and reload a database (using the -an option). If you create a strongly encrypted database, you must provide the encryption key to use the database or transaction log in any way. The algorithm used to encrypt the database is the algorithm specified by the -ea option. If you specify the -ek option without specifying -ea, the AES algorithm is used. Protect your key. Store a copy of your key in a safe location. A lost key will result in a completely inaccessible database, from which there is no recovery. |
-ep |
Prompts for an encryption key for the new database created if you unload and reload your database using the -an option. It provides an extra measure of security by never allowing the encryption key to be seen in clear text. If you specify -ep without specifying -an, the -ep option is ignored. If you specify -ep and -an, you must input the encryption key twice to confirm that it was entered correctly. If the keys don't match, the unload fails. |
-er |
Removes encryption from encrypted tables during an unload procedure. When rebuilding a database that has table encryption enabled, you must specify either -er or -et to indicate whether the new database has table encryption enabled, otherwise you get an error when attempting to load the data into the new database. The following command unloads a database (data.db) that has encrypted tables, into a new database (copy.db) that does not have encryption enabled, removing encryption from any encrypted tables: dbunload -an copy.db -er -c "UID=DBA;PWD=passwd;DBF=data.db;DBKEY=29bN8cj1z" |
-et |
Enables database table encryption in the new database (-an or -ar must also be specified). If you specify the -et option without the -ea option, the AES algorithm is used. If you specify the -et option, you must also specify -ep or -ek. You can change the table encryption settings for the new database to be different than those of the database you are unloading. When rebuilding a database that has table encryption enabled, you must specify either -er or -et to indicate whether the new database has table encryption enabled, otherwise you get an error when attempting to load the data into the new database. The following example unloads a database (data.db) that has encrypted tables, into a new database (copy.db) that has table encryption enabled, and uses AES_FIPS encryption with the key 34jh: dbunload -an copy.db -et -ea AES_FIPS -ek 34jh -c "UID=DBA;PWD=passwd;DBF=data.db" |
-g |
Controls whether materialized views and indexes are refreshed after a reload..
|
-ii | Uses the UNLOAD statement to extract data from the database, and uses the LOAD statement in the reload.sql file to repopulate the database with data. This is the default. |
-ix | Uses the UNLOAD statement to extract data from the database, and uses the Interactive SQL INPUT statement in the reload.sql file to repopulate the database with data. |
-k |
Populates the sa_diagnostic_auxiliary_catalog table. This table maps database object IDs for tables, users, procedures, and so on, from the source database to the tracing database. It also causes all histograms to be unloaded/reloaded. This option is used when creating a tracing database, that is, a database that receives diagnostic tracing information. Additionally, this option ensures that auditing is disabled on the tracing database, even if auditing is enabled on the production database. The sa_diagnostic_auxiliary_catalog table allows the server to simulate conditions that were present when tracing data was captured (for example, for use with Index Consultant). This option is most useful when specified with the -n option. |
-kd |
Reloads the database into a single dbspace file. This option is useful for creating a tracing database if the computer where the tracing database is being created does not have the same directory structure as the production database. |
-kdi number |
Specifies the number of times that the encryption key is hashed. Specify a whole number between 1 and 1000. The default value is 2, which results in the hash being applied 2000 times. The higher the number, the better security. If you are running the database on a slow computer, then a very high number of iterations could result in the database taking longer to start (once the database is running, there is no performance impact). This option must be specified with either the -ek or the ep option, as well as either the -ar or the -an option. |
-l |
Forces the current value of SYSTABCOL.max_identity to be preserved across a database rebuild. By default, when a database containing tables with AUTOINCREMENT columns is rebuilt, the database server calculates the next available value for each AUTOINCREMENT column based on the current contents of the tables. Usually this is enough; however, if rows have been deleted from the end of the range of values, values can be reused, which is not desirable. Specifying the -l option adds calls to the sa_reset_identity system procedure to the generated reload.sql script for each table that contains an AUTOINCREMENT value, preserving the current value of SYSTABCOL.max_identity. |
-m | Does not preserve user IDs for databases involved in replication. |
-n | Does not unload database data; reload.sql contains SQL statements to build the structure of the database only. If you want the reload.sql file to contain LOAD TABLE or INPUT statements, use -nl instead. |
-nl | Unloads the structure (the same behavior as the -n option), but the resulting reload.sql file also includes LOAD TABLE or INPUT statements for each table. No user data is unloaded when this option is used. When you specify -nl, you must also include a data directory so that the LOAD/INPUT statements can be generated, even though no files are written to the directory. This option allows you to generate a reload script without unloading data. You can unload the data by specifying -d. If a database contains a table whose data should not be unloaded, unloading the data for that table can be skipped using dbunload -d -e table-name. |
-no |
Unloads the database objects ordered by name. By default, dbunload generates objects in the order they were created. Specifying the -no option may be useful for comparing database schemas when the databases contain the same objects, but the creation order was different. Object definitions are grouped by object type in alphabetical order in the reload.sql file if -no is specified:
The object definitions are output in owner,name order. Sometimes a third element such as a foreign key, role name, or trigger name is included in the ordering. The -no option cannot be used with the -n, -nl, -ar, -an, or -ac option. To simplify comparisons, use -no option when comparing the reload scripts for databases that were created using the same version of the database server because of minor differences in the object definitions. Caution The generated file should not be used to create a new database because the object creation order can be important. For example, if procedure p2 calls procedure p1 and p1 returns a result set, it may be
important to define p1 before p2. Attempting to run a reload.sql script file generated with -no option results in an error.
An error is returned if this option is specified with the -up option. |
-o filename | Appends output messages to the named file. The location of this file is relative to the directory in which you run dbunload. |
-p char | Replaces the default escape character (\) for external unloads (dbunload -x option) with another character. This option is available only when you run this utility at a command prompt. |
-q | Runs in quiet mode; messages are not displayed. This option is available only when you run this utility at a command prompt. If you specify -q, you must also specify -y or the unload will fail if reload.sql already exists. |
-qr | Prevents progress messages from being created and displayed when loading tables and creating indexes. |
-r reload-file | Modifies the name and directory of the generated reload SQL script file. The default is reload.sql in the current directory. The directory is relative to the current directory of the client application, not the server. |
-ss | Suppresses the output of column statistics in the reload SQL script file. |
-t table,... |
Specifies a list of tables to be unloaded. By default, all tables are unloaded. Together with the -n option, this allows you to unload a set of table definitions only. Table names are always case insensitive, even in case sensitive databases. A reload.sql file created with the -t option should not be used to rebuild a database because the file will not include all the database tables. If a table has foreign keys referring to it, the database cannot be rebuilt without the contents of the table. Only use the -t option with the -d option to unload data for the tables identified by -t. |
-u | Prevents an index from being used to order data. Use this option if you are unloading a database with a corrupt index, so that the corrupt index is not used to order the data. Normally, the data in each table is ordered by the primary key or clustered index if one is defined for the table. |
-up |
Unloads user passwords (hashed value). You do not need to specify this option if you are performing an unload with reload (-ac, -an, or -ar option). An error is returned if this option is specified with the -no option. |
-v | Displays the name of the table being unloaded, and the number of rows that have been unloaded. This option is available only when you run dbunload at a command prompt. |
-xi | Performs an external unload by unloading data to the dbunload client, and then using the LOAD statement in the generated reload script file, reload.sql, to repopulate the database with data. |
-xx | Performs an external unload by unloading data to the dbunload client, and then using the Interactive SQL INPUT statement in the generated reload SQL script file, reload.sql, to repopulate the database with data. |
-y |
Replaces existing script files without prompting for confirmation. If you specify -q, you must also specify -y or the unload will fail if dbunload detects that a script file already exists. |
directory | Specifies the directory where the unloaded data is to be placed. The reload.sql script file is always relative to the current directory of the user. |
For an unload with reload into a new database (-an, -ao, -aob), you must have the SELECT ANY TABLE, SERVER OPERATOR, and ACCESS USER PASSWORD system privileges. For an unload with reload into an existing database (-ac) you do not need the SERVER OPERATOR system privilege.
For an unload without reload, you must have the SELECT ANY TABLE system privilege.
To unload passwords (-up option), you must have the ACCESS USER PASSWORD system privilege.
Passwords are only unloaded by default when you are performing an unload with reload (-ac, -an, -ar options). Otherwise, specify the -up option to unload passwords.
Ensure that there are no active transactions (including DDL) occurring on the database when you run the dbunload utility.
When using dbunload with a version 10.0.0 or later database, the version of dbunload used must match the version of the database server used to access the database. If an older version of dbunload is used with a newer database server, or vice versa, an error is reported.
With the Unload utility, you can unload a database and put a set of data files in a named directory. The Unload utility creates an Interactive SQL script file to rebuild your database. It also unloads all the data in each of your tables into files in the specified directory, in comma-delimited format. Binary data is properly represented with escape sequences.
An internal unload/reload unloads information about the current status of each user by issuing UPDATE ISYSUSER statements. An external unload/reload does not include this information and the status of all users is reset.
When you rebuild a database by unloading and reloading it, the rebuilt database may be smaller than the original database. This decrease in database size may be the result of indexing changes, and does not indicate a problem or a loss of data.
If you rebuild a version 11 or earlier database using the Unload utility (dbunload), the new database has global checksums enabled by default, even if the original database had checksums turned off. Although it is not recommended, you can disable global checksums for a database using the ALTER DATABASE statement.
You can also use the Unload utility to directly create a new database from an existing one. This avoids potential security problems with the database contents being written to ordinary disk files.
There are special considerations for database extraction (unloading) for remote databases involved in replication.
The -gl database server option controls the permissions required to unload data from the database.
The dbo user ID owns a set of system objects in a database, including views and stored procedures.
The Unload utility does not unload the objects that were created for the dbo user ID during database creation. Changes made to these objects, such as redefining a system procedure, are lost when the database is unloaded. Any objects that were created by the dbo user ID since the initialization of the database are unloaded by the Unload utility, and so these objects are preserved.
When you unload a database, changes to permissions on system objects are not unloaded. You must grant or revoke these permissions in the new database.
Before rebuilding your database, validate the reload process by reloading the database without any data, by running a command similar to the following:
dbunload -n -an new.db -c "UID=your-user-id;PWD=your-password;DBF=original-database-file"
Fix any problems that are identified in the original database before rebuilding it.
In the default mode, or if -ii or -ix is used, the directory used by dbunload to hold the data is relative to the database server, not to the current directory of the user.
If -xi or -xx is used, the directory is relative to the current directory of the user.
If no list of tables is supplied, the whole database is unloaded. If a list of tables is supplied, only those tables are unloaded.
Unloaded data includes the column list for the LOAD TABLE statements generated in the reload.sql file. Unloading the column list facilitates reordering of the columns in a table. Tables can be dropped or recreated, and then repopulated using reload.sql.
The LOAD TABLE statements generated by dbunload turn off check constraints and computed columns.
Exit codes are 0 (success) or non-zero (failure).
Refresh the materialized views in your database after rebuilding the database.
Tracing information is not unloaded as part of a database unload or reload operation. To transfer tracing information from one database to another, you must do so manually by copying the contents of the sa_diagnostic_* tables; however, this practice is not recommended.
The following options offer combinations of internal and external unloads and reloads: -ii, -ix, -xi, and -xx. A significant performance gain can be realized using internal statements (UNLOAD/LOAD) versus external commands (Interactive SQL INPUT and OUTPUT statements). However, internal statements are executed by the server so that file and directory paths are relative to the location of the database server. Using external commands, file and directory paths are relative to the current directory of the user.
You can specify whether to unload relative to the server or client using the UNLOAD statement.
When you use an external unload and reload to unload, reload, or rebuild a database and the character set of the database is incompatible with the character set of the host system on which dbunload is running, character set conversion may cause data to be corrupted as it is converted between the database character set and the host system's character set.
To avoid this problem, specify the database character set in the connection string for the database (-c and -ac options). For example, if the database character set is UTF-8, include "charset=utf-8" in the connection strings:
dbunload -c UID=user-ID;PWD=password; CHARSET=utf-8;DBF=filename -ac UID=user-ID; PWD=password;CHARSET=utf-8;Host=host-name -xx
When you perform an external unload, the beginning of reload.sql includes a commented CREATE DATABASE statement. This statement can be used to create a database that is equivalent to the one being unloaded.
If the unloaded database was created with version 9 or earlier of SQL Anywhere and had a custom collation, the COLLATION clause appears as follows:
COLLATION collation-label DEFINITION collation-definition
where collation-definition is a string that specifies the custom collation.
The only way to preserve a custom collation is to rebuild the database in a single step (internal unload). If you choose to unload the database, and then load the schema and data into a database that you create, then you must use one of the supplied collations.
If the unloaded database was created with strong encryption, the value of the KEY clause in the CREATE DATABASE statement appears as three question marks (???).
If a failure occurs during an internal rebuild of a database using -ar or -an, after the table data has been reloaded and any indexes on the table have been rebuilt, dbunload creates a file named unprocessed.sql in the current directory. This file contains all the statements that were not executed as a result of the failure, and also includes the statement that caused the failure as a comment. The following is an example of an unprocessed.sql file:
-- The database reload failed with the following error: -- ***** SQL error: the-SQL-error -- This script contains the statements that were not executed as a -- result of the failure. The statement that caused the failure is -- commented out below. To complete the reload, correct the failing -- statement, remove the surrounding comments and execute this script. /* the failing statement go */ setuser "DBA" go ... the remainder of the statements to be processed
Having this file gives you the opportunity to correct, remove, or alter the failing statement(s). The unprocessed.sql file is only created after all the table data and referential integrity constraints have been reloaded. Using Interactive SQL, you can connect to the new database and run the updated unprocessed.sql file. This allows you to complete the rebuild of the database without having to start the rebuild over again, which can save considerable time.
When the unprocessed.sql file is generated, dbunload stops and returns a failed error code to make other tools or scripts aware of the failed rebuild.
If a failure occurs during an internal rebuild of a database using -ar, the new database and transaction log file have the .dbr and .logr file extensions, respectively. Use the following steps to apply the unprocessed.sql file and finish the reload manually:
Start the new database.
Apply the updated unprocessed.sql file.
Shut down the database.
Move original-name.db and original-name.log to a new directory.
Rename the original-name.dbr and original-name.logr files to original-name.db and original-name.log respectively.
Run the following command:
dblog -t original-name.log original-name.db
When you rebuild a database that has table encryption enabled, you must specify either -er or -et to indicate whether the new database has table encryption enabled, otherwise you get an error when attempting to load the data into the new database.
To unload a strongly encrypted database, you must provide the encryption key. You can use the DatabaseKey (DBKEY) connection parameter to provide the key in the command. Or, to be prompted for the encryption key rather than entering it in plain view, you can use the -ep server option as follows:
dbunload -c "DBF=myenc.db;START=dbeng17 -ep"
If you are using the -an option to unload a database and reload into a new one, and you want to use the -ek or -ep options to set the encryption key for the new database, keep the following in mind:
If the original database is strongly encrypted, you need to specify the key for the original database using the DatabaseKey (DBKEY) connection parameter in the -c option, rather than using -ek or -ep.
Using the -ek and -ep options, it is possible to unload an unencrypted database and reload into a new, strongly encrypted database. When you use -ep and -an, you must confirm the key correctly or the unload fails.
If the original database is strongly encrypted, but the -ek and -ep options are not used, then the new database will be encoded with simple obfuscation.
The -ek and -ep options are ignored if -an is not specified. The dbunload -ek and -ep options apply to a new database, while the database server (dbeng17/dbsrv17) options and DBKEY= apply to existing databases.
When rebuilding databases involved in synchronization or replication, dbunload assumes that the encryption key specified with the -ek or -ep option is the encryption key of the original database, and the encryption key of the newly rebuilt database.
When encrypting the new database or enabling table encryption in the new database, specify an encryption key. The software uses Password-Based Key Derivation Function #2 (PBKDF2), which is part of the PKCS#5 standard to protect the key from brute-force attacks. The software repeatedly applies a cryptographic hash to the encryption key. Use the -kdi option to specify the number of times to apply the hash.
To unload a database run dbunload, specifying a DBA user and password, and referencing the database with the DBF= connection parameter, and using the -up option to unload passwords.
To reload a database, create a new database and then run the generated reload.sql script file through Interactive SQL.
To combine the unload and reload steps, follow the directions for unloading above, but add the -an option to specify the name of the new database file. See the descriptions of the -ac and -an options.
The following example unloads a database into a reload.sql file. The CREATE INDEX and LOAD TABLE statements are grouped inside BEGIN PARALLEL WORK statements.
dbunload -c "UID=DBA;PWD=sql;DBF=mydemo.db" -bp -r reload.sql