Use the mount command to attach the database to the destination or secondary Adaptive Server. The mount command decodes the information in the manifest file and makes the set of databases available. All the required supporting activities are executed, including adding database devices, if necessary, and activating them, creating the catalog entries for the new databases, and recovering them.
Before mounting the databases, use mount with listonly and modify the device pathnames at the destination Adaptive Server. Then use mount to actually mount the databases.
The mount limits the number of databases to eight in a single command.
WARNING! For every login that is allowed access to a database on the original Adaptive Server, a corresponding login for the same suid must exist at the destination Adaptive Server.
For permissions to remain unchanged, the login maps at the destination Adaptive Server must be identical to that on the source Adaptive Server.
mount database all from <manifest_file> [with listonly]
The manifest file is the binary file that describes the databases that are present on a set of database devices.
Operations that can perform character translations of the file contents (such as ftp) corrupt the manifest file unless done in binary mode.
Finds the path names listed on the manifest file from the source Adaptive Server:
mount database all from "/data/sybase2/mfile1" with listonly go
"/data/sybase1/d0.dbs" = "1dev1" "/data/sybase2/d14.dbs" = "1dev13"
When you have the path names, you can verify or modify them to meet your criteria at the destination Adaptive Server.
When the database is loaded to the secondary Adaptive Server, you then mount it.
mount database all from "/data/sybase2/mfile1" using "/data/sybase2/d0.dbs" = "1dev1", "/data/sybase2/d14.dbs" = "1dev13"
When the mount process has completed, the database is still offline. Use the online database command to bring the database online. You do not have to reboot the server.
Once databases are mounted on the destination Adaptive Server, certain settings are cleared on the mounted database:
Replication is turned off.
Audit settings are cleared and turned off.
Omni options, default remote location, and type are cleared.
Cache bindings are dropped for both the mounted databases and their objects.
Recovery order is dropped for the mounted databases and becomes the default dbid order.
You cannot use the mount command in a transaction.
You cannot mount a database on an HA-configured server.
When you mount databases onto an Adaptive Server:
Database IDs for the transported databases must be on the destination Adaptive Server. If the database ID is already in use in the destination Adaptive Server, the mount command displays a warning that dbcc checkalloc must be run on the database. Run checkalloc if the database is not being mounted for temporary use.
If the dbid is changed, all procedures are marked for recompiling in the database. This increases the time it takes to recover the database at the destination and delays the first execution of the procedure.
The manifest file contains the device paths known to the source Adaptive Server that created the manifest file. If the destination Adaptive Server accesses the devices with a different path, you can specify the new path to the mount command.
Use the mount command with listonly to display the old path:
mount database all from "/work2/Mpubs_file" with listonly go
"/work2/Devices/pubsdat.dat" = "pubs2dat"
If the new path for the device pubs2dat is /work2/Devices/pubsdevice.dat, (the Devices path in Windows) specify the new device in the mount command:
mount database all from "/work2/Mpubs_file" using "/work2/datadevices/pubsdevice.dat" = "pubs2dat"
ANSI SQL – Compliance level: Transact-SQL extension.
mount requires an sa or dba role.
Commands unmount, quiesce database
