mount

Description

Attaches a database to a destination or secondary Adaptive Server.

The mount command decodes the information in the manifest file and makes the set of databases available. The mount command differs from other copying procedures such as the bcp bulk copy utility in that all 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.

If you are using different device names at the destination Adaptive Server when mounting the databases, use mount with listonly and modify the device path names at the destination server. Then use mount to actually mount the databases.

Syntax

mount database all | database_mapping[, database_mapping, ...]
	from "manifest_file" 
	[using device_mapping [, device_mapping...] 
		[with listonly]

	database_mapping:
			origdbname as newdbname
		|	newdbname = origdbname
		|	origdbname
		|	newdbname

	device_mapping
			logical_device_name as new_physical_name
		|	new_physical_name = logical_device_name
		|	original_physical_name
		|	new_physical_name

Parameters

Examples

Example 1

Finds the path names listed on the manifest file from the source Adaptive Server:

mount database all from "/data/sybase2/mfile1" with listonly
go

[database]
  mydb
[device]
  "/data/sybase1/d0.dbs" = "1dev1"
  "/data/sybase2/d14.dbs" = "1dev13"

When you use the path names different from the source ones, verify or modify them to meet your criteria at the destination Adaptive Server.

Example 2

After the database devices are copied 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 or databases are still offline. Use the online database command to bring them online. You need not restart the server.

Example 3

The destination server can be the same as the source server. In this case, the database names must be mapped to a different name, and the logical device names will be internally renamed.

1. Create an exact copy of database mydb in the same server:

   1> quiesce database mydb_tag hold mydb for external dump to 
      "/data/mydb.manifest"
   2> go
   

2. Copy the OS file:

   $ cp /data/sybase2/mydb.dbs /data/sybase2/mydb_copy.dbs
   

3. You can now mount it as a copy:

   1> quiesce database mydb_tag release
   2> go
   1> mount database mydb as mydb_copy
   2> from "/data/mydb.manifest"
   3> using mydb_dev as "/data/sybase2/mydb_copy.dbs"
   3> go
   

The physical device //data/sybase2/mydb_copy.dbs/ is automatically assigned a machine-generated logical name with the format Cccc$<mydb_dev> where:

• C – is [A–Z]

• c – is [A–Z, 0–9], and refers to the encoded logical device number

• mydb_dev – contains up to 26 characters from the old logical device name.

Database IDs for the transported databases should not exist on the destination Adaptive Server. Because the database has been mounted on the same server, the database ID had to be changed. The allocation pages in the mounted device keep the original database ID, and that information is used by the disk refit command. Use the dbcc checkalloc command to reconcile the dbid after running mount database so that disk refit can work on the mounted devices. Run checkalloc if the database is not being mounted for temporary use.

Usage

• The using clause allows you to define a mapping via the “=” sign or the “as” clause.

• If there are more than one device, a mapping can be one using “=” and another using “as.”

• In both databases and devices, you can map devices by name, specifying both logical and physical, and by order. If a database is mapped by name, all databases must be mapped by name and vic eversa. The same happens for devices.

• You cannot mount a subset of a transported set of databases at the destination Adaptive Server; all databases and their devices in the manifest file must be mounted together.

• When executing the mount command at the destination Adaptive Server:

  • The page size in the destination Adaptive Server must be equal to the page size in the source Adaptive Server.

  • There must be enough devices configured at the destination Adaptive Server to successfully add all the devices belonging to the mounted databases.

  • If the logical device you are mounting from the source Adaptive Server has the same name as the logical device on the destination Adaptive Server, these devices are automatically renamed unless you include an alias with the mount command.

    If the physical device name already exists on the destination Adaptive Server, you must rename the physical device name on the source Adaptive Server at the operating system level and provide the new physical device name with the mount command.

  • The log version must be the same in the source and destination Adaptive Servers.

  • You cannot mount a database from an Adaptive Server with a higher major version number. For example, you cannot mount a 15.0 version database on a 12.5.x version of Adaptive Server.

  • The platforms of the source and destination Adaptive Servers must be the same.

  • Differences in the sort order or character set are resolved by rules followed by load database. A database with a different character set can be mounted only if the sort order is binary.

mount database and unmount database are supported in the Cluster Edition. However, these commands may be aborted if an instance failover recovery takes place while you are using these commands. In this case, the user must re-issue the command when the instance failover recovery is complete

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.

• Component Integration Services 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 server configured for high availability.

When you mount databases onto an Adaptive Server, if you change the dbid of the database you are mounting, all procedures are marked for recompilation 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.

1. Use the mount command with listonly to display the old path:

   mount database all from "/work2/Mpubs_file" with listonly
   go
   

   [database]
     mydb
   [device]
     "/work2/Devices/pubsdat.dat" = "pubs2dat"
   

2. 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"
   

   If the logical device names exist in the destination server, they will be renamed using an automatically generated unique name.

Standards

ANSI SQL – Compliance level: Transact-SQL extension.

Permissions

mount requires an SA role.

Auditing

Values in event and extrainfo columns of sysaudits are:

See also