Sybase Business Intelligence Solutions - Database Management, Data Warehousing Software, Mobile Enterprise Applications and Messaging
Sybase Brand Color Bar
delete

Search for    in all of Sybase.com
view all search results right arrow
  blank
 
 
 
 
 
 
 
 
 
 
Support > Technical Documents > Document Types > Technote > BASICS OF BACKUP SERVER

BASICS OF BACKUP SERVER

This TechNote discusses the basic funtionality of Backup Server, its resource requirements, and some compatibility issues.
 
RSS Feed
 
 
 

Contents

What Is Backup Server?

Backup Server is an Open Server-based utility that handles all dumps and loads for SQL Server releases 10.0 and later. Backup Server provides flexible syntax for the dump and load commands and eliminates the need for the console program. Because it is a separate collection of processes, Backup Server does its tasks independently from the SQL Server, meaning that users experience much less performance degradation during dumps and loads.

How Does It Work?

Backup Server runs on the same machine as SQL Server (or on the same cluster, for Digital OpenVMS). You can perform dumps and loads over the network by using two Backup Servers, one on the local machine and the other on a remote machine.

When you dump database/transaction to dump devices known by a remote Backup Server (through sp_addumpdevice), the local Backup Server reads the database devices and sends the data over the network to the remote Backup Server, which stores it on the dump devices. When you use the load command, the local Backup Server sends instructions over the network to the remote Backup Server. The remote Backup Server reads the data from the dump devices and sends it back to the local Backup Server, which writes the data to the database devices. A network dump performs only as well as does the network supporting it, leading in many cases to significant performance decreases.

Backup Server contains several major features to allow users to implement an unattended backup policy to improve dump and load performance. SQL Server is able to detect remaining space on database segments and allows automatic dumping and truncation of the transaction log when free space falls below particular thresholds. Backup Server:

  • Senses dump device type and density automatically
  • Supports writing multiple dumps to the same volume
  • Supports dump striping (interleaving of dump data across several volumes)

Dump Striping

Backup Server supports simultaneous dumps and loads with a maximum of 32 backup devices, in parallel, per dump or load. The number of simultaneous dumps and loads is limited by the system's configured maximum number of open files, and by shared memory resources. On Digital OpenVMS, that is the per- process limit. On UNIX, there is a limit on the number of processes per user ID, and a system-wide limit, since UNIX forks a separate process for each device to do the I/O. Refer to the System Administration Guide Supplement for your platform for more information on the maximum number of open files.

See SYBASE SQL Server Utility Programs for UNIX for more information on the Backup Server's configurable parameters:

  • -C specifies the number of server connections
  • -N specifies the number of network connections
  • -c specifies the Backup Server dump device configuration file (SQL Server 11.0 and later releases). For more information on the dump device configuration file, see the Backing Up and Restoring User Databases chapter of the SQL Server System Administration Guide.
See the SQL Server Reference Manual for more information about dump and load syntax, particularly in the area of multi-file dumps to a single volume set and single database dumps across a multi-volume set.

See "Developing a Backup and Recovery Plan" in the System Administration Guide for more information on the capabilities of the Backup Server.

Shutdown

Backup Server supports immediate or deferred shutdown. You must connect to your SQL Server to issue the shutdown command to Backup Server.

Deferred Shutdown The syntax for deferred shutdown is as follows:

1> shutdown backup_server_name 
2> go
This shutdown permits dumps and loads in progress to complete (including volume change notifications for these sessions), but will not permit initiation of new dumps and loads. When the last dump or load has completed, Backup Server disconnects and exits from all SQL Servers.

Immediate Shutdown The syntax for immediate shutdown is as follows:

1> shutdown backup_server_name with nowait
2> go
This causes Backup Server to drop all connections immediately and to exit.


Note
The shutdown command must be typed while you are logged into SQL Server. In the syntax examples above, backup_server_name is the local/remote Backup Server name known internally to SQL Server (that is, it is not the network name). If you are using only one Backup Server, the backup_server_name should be SYB_BACKUP.

What Is Required to Run Backup Server?

Backup Server is an Open Server application and an independent process. As such, it uses memory and CPU resources, and acts like an independent SQL Server.

Name Entries

sybinit inserts entries for Backup Server into the interfaces file and the sysservers table in the master database (where it is listed as "SYB_BACKUP"). If you have a remote Backup Server on another machine, put your interfaces file on a file server accessible to both machines, or else copy the remote Backup Server's entry from the remote interfaces file to the local one.

The definition for the remote Backup Server must exist in the interfaces file on both the local and the remote system.


WARNING!
The local Backup Server entry in sysservers must have an accurate network name. Run sp_helpserver to verify this. If entries are inaccurate, SQL Server may contact the wrong Backup Server and write to or read from the wrong devices.
Additionally, if the Backup Server start-up option -S specifies a particular server name, all interfaces files must use that name, not another. In other words, you cannot use an alias for your Backup Server in the interfaces file as you can for other servers. For example:

  • If you have started a Backup Server with the -SSYB_BACKUP option, and
  • You have BS2 aliased to SYB_BACKUP in your interfaces file, and
  • You attempt to do a dump to dumpdev at BS2,
then you will receive the following errors as SQL Server assumes you are dumping to a remote Backup Server:

Backup Server: 5.16.2.1: DB-Library error, error 
number 20011, severity 8:
Maximum number of DBPROCESSes already allocated.
Backup Server: 5.3.2.1: Cannot open a connection to the slave site 'REM_BACKUP_SERVER'
Backup Server: 5.16.2.1: DB-Library error, error 
number 20018, severity 5:
General SQL Server error: Check messages from the SQL Server.
Backup Server: 5.7.2.4: RPC ('as_arch_device') execution failed.

UNIX Memory Requirements

Under UNIX, Backup Server uses shared memory during dump and load (Digital OpenVMS does not use shared memory, so these calculations do not apply). The size and number of shared memory segments, and the number of process attachments to those segments, vary depending on the number of stripes and whether the dump is remote:

  • There is one session handler for each dump or load currently in progress.
  • There is one stripe service task for each stripe being used by the dump or load. Local Stripe
  • The Backup Server process creates and attaches to one shared memory segment. The size of this memory segment is 2,048 bytes * the number of the local stripes.
  • Each local stripe also creates a shared memory segment. The Backup Server process does not attach to this segment. Each local stripe may allocate up to 110K of shared memory (164K on HP-UX). sybmultbuf is a process forked by the Backup Server which reads and writes the data from the database devices. Only the two sybmultbuf processes associated with each local stripe attach to this segment. Remote Backup Server
The remote Backup Server requires different calculations for shared memory:

  • The remote Backup Server allocates up to 54K of shared memory per stripe.
  • The Backup Server process attaches to one shared memory segment per remote stripe. For example, if a local Backup Server dumps to a remote Backup Server with two stripes, the remote Backup Server creates two shared memory segments and attaches to both. Shared Memory Calculations
Some platforms require a configuration parameter (SHMSEG) for the number of shared memory segments to which a process can attach. During a local dump or load, the sybmultbuf process attaches to one or two shared memory segments, depending on whether it is reading (one segment) or writing (two segments) the data. The main Backup Server process only attaches to one segment per active dump or load:

  • Local dump
  • Backup Server process:
    2048 bytes * number of local stripes + (Backup Server process)
  • sybmultbuf, UNIX except HP:
    108K * number of local stripes
  • sybmultbuf, HP-UX:
    164K * number of local stripes
The Backup Server process attaches to one shared memory segment per active dump. The sybmultbuf process attaches to two.

  • Remote site
  • UNIX except HP:
    54K * number of remote stripes (active at one time)
  • HP-UX:
    size = 54K * number of remote stripes (active at one time) + 64K
The Backup Server process attaches to one shared memory segment per remote stripe. The sybmultbuf process attaches to two.

System Defaults The default number of shared memory segments a process can attach to varies from platform to platform. Refer to the System Administration Guide Supplement for your platform for this figure. If more than six stripes are to be dumped, the SHMSEG operating system configuration parameter needs to be increased.

Because Digital OpenVMS has true asynchronous I/O built in, the Backup Server itself does all I/O and there is no sybmultbuf equivalent. There is no shared memory because there are no subprocesses ("child" processes) communicating with each other.

Tape Dump Device Configuration File (SQL Server release 11.0 and later)

In SQL Server release 11.0 and later, sybinit prompts you for the name and location of a Backup Server configuration file during configuration of a Backup Server. The default name and location is:

$SYBASE/backup_tape.cfg
When Backup Server encounters a dump device with which it is unfamiliar, it issues calls to the operating system in an attempt to get about the tape dump device. Backup Server writes this information to the configuration file for future use.

The configuration file is a standard ASCII file.

Multi-File, Multi-Volume Dumps

The Backup Server allows writing of data from successive dumps to the same tape by default if the dump device type supports it. This feature makes efficient use of high-density archive media such as 8-mm tape.

There are three main categories of devices:

  • Single-file, single-volume. These types of devices can contain, at most, one Sybase dump and that the dump resides entirely within the file or partition.
  • Single-file, multi-volume. A dump on these media may span multiple volumes, but a set of volumes may collectively contain, at most, one dump. These devices do not allow backspacing, and attempts to append multiple files will prompt you for overwrite confirmation and will overwrite the previous contents if you enter "PROCEED."
  • Multi-file, multi-volume. A given volume of one of these media types may contain more than one dump, and the last dump on a volume may continue onto other volumes.
SQL Server 11.0 and later releases support multi-file, multi- volume dumps on all 4mm, 8mm, DLT, and QIC tape drives, provided that the operating system supports the tape drive.

SQL Server 10.x is more restrictive about supported devices. The following table summarizes hardware requirements for dump and load commands in SQL Server 10.x.

Tape Device Hardware Requirements in SQL Server 10.x

The following table lists device names and specific hardware requirements for dump/load to and from a tape device. The System Administration Guide Supplement for your platform may have further information. In the table below, N stands for the device number.
Platform Type Device Name
HP9000 4-mm (/SCSI and /HPIB) /dev/rmt/Nmn
9-track (/SCSI and /HPIB) /dev/rmt/Nmn
AT&T 8-mm/SCSI (5GB and 2.2GB) /dev/nrmtN
4-mm/SCSI /dev/nrmtN
RS6000 9-track/SCSI /dev/rmtN.[0- 127]
8-mm DAT/SCSI (5GB and 2.2GB) /dev/rmtN.[0- 127]
QIC/SCSI (1/4-inch cartridge) /dev/rmtN.[0- 127]
SunOS 4.x (BSD) 9-track/SCSI /dev/nrmtN
QIC/SCSI (1/4-inch cartridge) /dev/nrarN
8-mm/SCSI (5GB and 2.2GB) /dev/nrstN
Sun Solaris 2.x (SPARC) 9-track See "Sun Solaris 2.x"<z- Ignore> on page -12.
1/4-inch cartridge
8-mm/SCSI (5GB and 2.2GB)
Digital OpenVMS VAX 9-track (/HSC and /DSSI) See "Digital OpenVMS"<z -Ignore> on page -13.
8-mm (/HSC 5GB and 2GB and /DSSI)
TK50 (/HSC and /DSSI)
Digital OpenVMS Alpha 8-mm/SCSI See "Digital OpenVMS"<z -Ignore> on page -13.
9-track
4-mm DAT/SCSI
Digital UNIX 4-mm DAT/SCSI See "Digital UNIX"<z- Ignore> on page -12.
TZ85I
Novell Netware 1/4­inch cartridge N (from the list device command)
8-mm N (from the list device command)
OS/2 e:tmpdbase. dmp
Windows NT 1/4-inch cartridge .TAPEN
4mm DAT .TAPEN
8mm DAT .TAPEN
SCO UNIX 1/4-inch cartridge QIC /dev/ct0 or /dev/Stp0
1/4-inch SCSI QIC /dev/Stp0
4mm SCSI /dev/Stpdevic e#
8mm SCSI /dev/Stpdevic e#


Note
QIC devices are single-file devices. They do not allow backspacing and attempts to append multiple files to such a device will prompt you for overwrite confirmation.
SQL Server 10.x requires non-rewinding devices so that Backup Server can control the positioning of the tape device.

Sun Solaris 2.x

For Sun Solaris 2.x environments, tape device names are constructed as follows:

/dev/rmt/ unit_number density [BSD behavior] no rewind

where density is "l" (low), "m" (medium), "h" (high), or "c" (compressed); and unit_number is a logical number that uniquely identifies the tape drive or unit.

Tape device names indicating BSD behavior are used during installation, but should not be used with Backup Server.

Digital UNIX

For Digital UNIX environments, tape device names are constructed as follows:

/dev/[n]nrmt/unit_number density

where density is "a" or "l" (low), "m" (medium), or "h" (high); [n] indicates "no rewind"; and unit_number is a logical number that uniquely identifies the tape drive or unit.

Digital OpenVMS

For Digital OpenVMS environments, there is no standard device name for tape devices. Some typical names are: mua0, mub1, msa0. The devices are named as follows:

type spec unit

where:

  • type is the controller type
  • spec is the controller specifier in the backplane
  • unit is the unit number on the controller
For example, tape device mub1 is unit 1 of the b controller of an mu type controller.

HP-UX

For HP-UX environments, tape device names are constructed as follows:

/dev/rmt/controller_number device number density [compression]no rewind

where density is "l" (low), "m" (medium), or "h" (high).

Localization Files

Backup Server is an Open Server application, so it requires the $SYBASE/locales/locales.dat ([SYBASE.LOCALES]LOCALES.DAT on Digital OpenVMS) files that are required by Open Server, plus some additional files for each character set. Here is the list for the us_english, iso_1 character set:

locales/us_english/iso_1/bslib.loc
locales/us_english/iso_1/common.loc
locales/us_english/iso_1/cslib.loc
locales/us_english/iso_1/dblib.loc
locales/us_english/iso_1/libdna.loc
locales/us_english/iso_1/libinsck.loc
locales/us_english/iso_1/libsdna.loc
locales/us_english/iso_1/libssri.loc
locales/us_english/iso_1/libtli.loc
locales/us_english/iso_1/tcllib.loc
locales/us_english/iso_1/oslib.loc

Note
libsdna.loc is required for Digital OpenVMS only; libtli.loc is required for Sun Solaris 2.x only.
Identical sets of files are located in each of the character set and language directories:

locales/us_english/cp437/
locales/us_english/cp850/
locales/us_english/iso_1/
locales/us_english/mac/
locales/us_english/roman8/
Only U.S. English is provided with the basic product. If you have purchased one of the language modules, the same set of locales files is provided for each character set supported for the language.

Following are the locations of files needed for some other languages:

Japanese

 locales/japanese/deckanji/
locales/japanese/eucjis/
locales/japanese/sjis/
locales/us_english/deckanji/
locales/us_english/eucjis/
locales/us_english/sjis/

French

 locales/french/cp437/
locales/french/cp850/
locales/french/iso_1/
locales/french/mac/
locales/french/roman8/

German

 locales/german/cp437/
locales/german/cp850/
locales/german/iso_1/
locales/german/mac/
locales/german/roman8/
Individual locales file names are the same for Digital OpenVMS, with paths like the following:

[SYBASE.LOCALES.US_ENGLISH.ISO_1]BSLIB.DOC
Additionally, Backup Server requires the file charset.loc in at least the default character set subdirectory (charsets/iso_1/charset.loc) and at least the default sort-order file (charsets/iso_1/roman8.srt for HP; charsets/iso_1/binary.srt for other platforms).

By default, Backup Server uses the $SYBASE/locales/locales.dat file's entry for platform default as the locale. You can override this with the LANG shell variable or any of the Open Server language variables. With SQL Server release 10.0.1, you can use the backupserver command's -J option (the option is /character_set for Digital OpenVMS) to define the Backup Server's character set. See the backupserver entry in the SQL Server Utility Programs manual for your platform for more details.


Note
Backup Server may issue a message informing you that SQL Server's character set is different from Backup Server's, which may lead you to worry about database corruption if you are doing local or remote backups to Backup Servers with different character sets. However, there is no need for concern. This is only an informational message.
Backup Server does not convert the data pages from the Server database device when performing dumps or loads. Localization changes are made only for messages passed back to the client. The rules are:

1. Backup Server sends messages to SQL Server in SQL Server's character set but in the client's language.

2. Backup Server reads pages from the database and writes them to an archive device, and vice versa. It does not interpret the data. It only copies it. No pages are ever changed while they are being dumped or loaded.

Additional Requirements

  • SQL Server must be configured for remote access. You may need to restart SQL Server if you have changed from this default behavior.
  • On UNIX systems, the user (usually "sybase") who starts the Backup Server process must have write permission for the /tmp directory.
  • The user who starts the Backup Server process must have write permission for the dump devices and read permission for the database devices.

Compatibility Issues

An important goal of Sybase's dump/load architecture is to preserve compatibility with preceding releases. However, there are several dump and load compatibility issues to consider when moving from one SQL Server release level to another:

  • Sybase does not officially support dumping on one platform and loading to another.
  • You can load a 10.x dump into an 11.0 or later SQL Server.
  • You cannot load a pre-10.x dump into a 10.x or later SQL Server.
  • You cannot load a 10.x or later dump into a pre-10.x SQL Server.
  • To make your pre-11.0 load scripts work in 11.0 or later SQL Server, add the following command after your load command:
    1> online database database_name
    2> go
    
    

 

DOCUMENT ATTRIBUTES
Last Revised: Aug 21, 1998
Product: SQL Server
Technical Topics: Performance & Tuning
  
Business or Technical: Technical
Content Id: 1270
Infotype: Technote
 
 
 

© Copyright 2014, Sybase Inc. - v 7.6 Home / Contact Us / Help / Jobs / Legal / Privacy / Code of Ethics