Increases the amount of space allocated to a database, as well as to the modified pages section of an archived database. Alters one or more database-wide properties such as DML logging level, defaults for compression, in-row large object (LOB) storage, and so on.
alter database database_name [on {default | database_device} [= size] [, database_device [= size]]...] [log on {default | database_device} [= size] [, database_device [= size]]...] set { [durability = { no_recovery | at_shutdown | full}] [[,] dml_logging = {full | minimal} ] [[,] template = { database_name | NULL}] [, [no] async_init] [, compression = {none | row | page}] [, lob_compression = {compression_level | off}] [,] inrow_lob_length = value [log off database_device [= size | [from logical_page_number] [to logical_page_number]] [, database_device [= size | [from logical_page_number] [to logical_page_number]] [with override] [for load] [for proxy_update]
is the name of the database. The database name can be a literal, a variable, or a stored procedure parameter.
indicates a size and location for the database extension. If you have your log and data on separate device fragments, use on for the data device and log on for the log device.
indicates that alter database can put the database extension on any default database devices (as shown by the sp_helpdevice stored procedure in “System Procedures,” in Reference Manual: Procedures). To specify a size for the database extension without specifying the exact location, use:
on default = size
To change a database device’s status to default, use sp_diskdefault.
is the name of the database device on which to locate the database extension. A database can occupy more than one database device with different amounts of space on each. Use disk init to add database devices to Adaptive Server®.
is the amount of space to allocate to the database extension. The following are example unit specifiers, using uppercase, lowercase, single and double quotes interchangeably: “k” or “K” (kilobytes), “m” or “M” (megabytes), “g” or “G” (gigabytes), and “t” or “T” (terabytes). Sybase® recommends that you always include a unit specifier. Quotes are optional if you do not include a unit specifier. However, you must use quotes if you include a unit specifier. If you do not provide a unit specifier, the value provided is presumed to be in megabytes.
If you do not specify a value, alter database extends a database by 1MB or 4 allocation unit, whichever is larger. Minimum amounts are:
Server’s logical page size |
Database extended by |
---|---|
2K |
1MB |
4K |
1MB |
8K |
2MB |
16K |
4MB |
indicates that you want to specify additional space for the database’s transaction logs. The log on clause uses the same defaults as the on clause.
determines the durability level of the database, and is one of:
full – all transactions are written to disk. This is the default if you do not specify a durability level when you create the database, and ensures full recovery from a server failure. All system databases except tempdb use this durability level (the traditional durability level for disk-resident databases). tempdb uses a durability level of no_recovery.
no_recovery – transactions are durable only while the server is running. All durability is lost if the server fails or is shut down politely. For disk-residents databases with durability set to no_recovery, Adaptive Server periodically writes data at runtime to the disk devices, but in an uncontrolled manner. After any shutdown (polite, impolite, or server failure and restart) a database created with no_recovery is not recovered, but is re-created from the model or, if defined, the template database.
at_shutdown – transactions are durable while the server is running and after a polite shutdown. All durability is lost if the server fails.
Enables or disables asynchronous database initialization.
indicates the level of compression alter database applies to newly created tables in this database.
none – the data is not compressed.
row – compresses one or more data items in an individual row. Adaptive Server stores data in a row-compressed form only if the compressed form saves space compared to an uncompressed form.
page – when the page fills, existing data rows that are row-compressed are then compressed using page-level compression to create page-level dictionary, index, and character-encoding entries.
Adaptive Server compresses data at the page level only after it has compressed data at the row level, so setting the compression to page implies both page and row compression.
Determines the compression level for the newly created table. Selecting off means the table does not use LOB compression.
Table compression level:
0 – the lob column is not compressed.
1 through 9 – Adaptive Server uses ZLib compression. Generally, the higher the compression number, the more Adaptive Server compresses the LOB data, and the greater the ratio between compressed and uncompressed data (that is the greater the amount of space savings, in bytes, for the compressed data versus the size of the uncompressed data).
However, the amount of compression depends on the LOB content, and the higher the compression level , the more CPU-intensive the process. That is, level 9 provides the highest compression ratio but also the heaviest CPU usage.
100 – Adaptive Server uses FastLZ compression. The compression ratio that uses the least CPU usage; generally used for shorter data.
101 – Adaptive Server uses FastLZ compression. A value of 101 uses slightly more CPU than a value of 100, but uses a better compression ratio than a value of 100.
specifies the number of bytes for an in-row text or image LOB column, and the number of characters for an in-row Unitext LOB column.
removes unwanted portions of the log for the database from the specified database device. Using log off decreases the amount of space allocated to the log of a database, as well as to the modified pages section of an archive database.
You cannot use log off with any other alter database parameter, including log on, for load, or with override.
specifies the amount of space at the end of the device that the command should affect. For this purpose, the end of a device is the highest-numbered logical page used by this database on that device. This command specifies physical storage, removing every log page on the specified device from the database:
alter database sales_db log off mylogdev
Size specifications round up to fit an exact number of allocation units. In an installation using a 16KB logical page size, you remove 52MB, not 50, because each allocation unit on that server is 4MB. The only time Adaptive Server removes less space than specified is when the database’s log segment uses less than that much space on that device.
identifies the first page number affected by this command. Adaptive Server automatically adjusts the number to indicate the allocation page’s page ID. The default from location is the lowest numbered logical page on the device.
identifies the last page affected by the command. Only complete allocation units (multiples of 256 pages) can be removed, so Adaptive Server automatically adjusts the page number upwards to the last page in the allocation unit. If logical_page_number is the exact page number of an allocation page (that is, it is divisible by 256), that allocation unit is unaffected. For example, to 512 affects pages up to but not including page 512.
The default to location is the highest-numbered logical page on the device.
indicates the level of logging for insert, update, and delete commands. full (the default) records all changes to the log for a complete record of all transactions. If the database uses minimal logging, Adaptive Server attempts to not log row or page changes to syslogs. However, Adaptive Server may generate some in-memory logging activity to support run-time operations such as rolling back transactions.
determines the template the database uses. One of:
database_name – user database that is disk-resident at full durability, and in a usable state.
NULL – removes the binding to the current template database. The database uses model as its template database during subsequent server restarts.
forces Adaptive Server to accept your device specifications, even if they mix data and transaction logs on the same device, thereby endangering up-to-the-minute recoverability for your database. If you attempt to mix log and data on the same device without using this clause, the alter database command fails. If you mix log and data, and use with override, you are warned, but the command succeeds.
is used only after create database for load, when you must re-create the space allocations and segment usage of the database being loaded from a dump.
forces the resynchronization of proxy tables within the proxy database.
Adds 3MB (1,536 pages) to a user database configured for 2K logical pages on a default database device:
alter database mydb
Adds 3MB to the space allocated for the pubs2 database on the database device named newdata:
alter database pubs2 on newdata = 3
Adds 10MB of space for data on userdata1 and 2MB for the log on logdev for a server configured for 2K logical pages:
alter database production on userdata1 = "10M" log on logdev = '2.5m'
Changes the durability level of pubs5_rddb, a relaxed-durability database to change it to a regular database with full durability:
alter database pubs5_rddb set durability = full
Alters the template for the pubs3 database:
alter database pubs3 set template = new_pubs_template_db
Changes the durability level of a disk-resident database with relaxed durability:
alter database pubs7 set durability=at_shutdown
Changes the DML logging level for the model database, which is set to a durability level of full. Any databases created from model after this change inherit the minimal logging level property:
alter database model set dml_logging = minimal
Changes pubs2 database to page-level compression:
alter database pubs2 set compression = page
Changes the pubs2 database to use LOB compression:
alter database pubs2 set lob_compression = 100
This example modifies the pubs database to change the length of its in-row LOB columns to 400 bytes:
alter database pubs set inrow_lob_length = 400
Removes 50MB of database sales_db from device mylogdev:
alter database sales_db log off mylogdev='50M'
This example removes the highest-numbered logical pages of sales_db that are on mylogdev, up to a maximum of 50MB.
Removes space for database sales_db from device mylogdev, specifying exactly which pages are to be removed:
alter database sales_db log off mylogdev from 7168 to 15360
Because logical page 15360 is an allocation page, this example affects all logical pages on mydev from 7168 through 15359. It does not, however, affect page 15360, nor does it affect any pages in the named range that are not physically located on mylogdev.
Quotes are optional if you do not include a unit specifier. However, you must use quotes if you include a unit specifier.
Adaptive Server reports an error if the total size of all fixed-length columns, plus the row overhead, is greater than the table’s locking scheme and page size allows.
Because Adaptive Server allocates space for databases for create database and alter database in chunks of 256 logical pages, these commands round the specified size down to the nearest multiple of allocation units.
You can specify the size as a float datatype, however, the size is rounded down to the nearest multiple of the allocation unit.
Although Adaptive Server does create tables in the following circumstances, you will receive errors about size limitations when you perform data manipulation language operations:
If the length of a single variable-length column exceeds the maximum column size.
For data-only locked tables, if the offset of any variable-length column other than the initial column exceeds the limit of 8191 bytes.
If Adaptive Server cannot allocate the requested space, it comes as close as possible per device and prints a message telling how much space has been allocated on each database device.
You must be using the master database, or executing a stored procedure in the master database, to use alter database.
You can expand the master database only on the master device. An attempt to use alter database to expand the master database to any other database device results in an error message. For example, use:
alter database master on master = 1
Each time you allocate space on a database device with create database or alter database, that allocation represents a device fragment, and the allocation is entered as a row in sysusages.
If you use alter database on a database that is being dumped, alter database cannot complete until the dump finishes. Adaptive Server locks the in-memory map of database space use during a dump. If you issue alter database while this in-memory map is locked, Adaptive Server updates the map from the disk after the dump completes. If you interrupt alter database, Adaptive Server instructs you to run sp_dbremap. If you do not run sp_dbremap, the space you added does not become available to Adaptive Server until you restart the server.
You can use alter database on database_device on an offline database.
You can use alter database to add space to the modified pages section of an archive database at any time, not only when space runs out. Increasing the space in the modified pages section allows a suspended command to resume operation. The syntax is:
alter database database_name [ on database_device [= size] [, database_device [= size]]...]
You cannot set specify model, master or sybsystemdb as the template database.
Setting the database name in the use template claue to NULL removes the binding to any existing template database, and defines model as the template database.
Altering the template definition of a database that appears earlier in the database recovery order sequence than its template database automatically reorders the recovery order so the new template database appears prior to its dependent database in the database recovery order when you restart the server.
If you change the settings for durability or dml_logging, alter database automatically attempts to set the databases to single-user mode before executing the command. You can manually set the database to single-user mode before you issue alter table.
Databases must be in single-user mode before you can change the durability level setting.
You can increase the size of an in-memory database only on in-memory storage caches that already host the in-memory database.
You cannot change the durability level of system, template, or local temporary databases.
The load sequence is broken when you change the durability level of the database to full. For example, for a disk-resident database using full durability, if you:
Dump a database.
Perform a dump transaction.
Perform a second dump transaction.
Changed the durability to no_recovery.
Changed the durability to full.
You cannot perform a third dump transaction. Instead, you must perform a full dump database.
Back up the master database with dump database after each use of alter database. This makes recovery easier and safer in case master becomes damaged.
If you use alter database and do not back up master, you may be able to recover the changes with disk refit.
To increase the amount of storage space allocated for the transaction log when you have used the log on extension to create database, give the name of the log’s device in the log on clause when you issue alter database.
If you did not use the log on extension of create database to place your logs on a separate device, you may not be able to recover fully in case of a hard disk failure. In this case, you can extend your logs by using alter database with the log on clause, then using sp_logdevice to move the log to its own devices.
set compression specifies the database-wide compression level, which applies only to newly created tables.
You can use set lob_compression by itself or with other set subclauses. However, other set subclauses require the database to be in single-user mode (for example, if you change the durability level of the database).
Use inrow_lob_length to increase or decrease the in-row LOB length database-wide.
Changing the inrow_lob_length affects the creation of LOB columns in future create table or alter table add column commands. The valid values are within the range of 0 to the logical page size of the database.
Regarding the log off variant of alter database:
Although the log off option specifies the range the range of pages to be removed as logical pages, it is the associated physical pages that are actually removed. The logical pages remain in the database as unusable since they form a hole. A hole is one or more allocation units for which there is no associated physical storage.
Information about which allocation units—space that is divided into units of 256 data pages when you create a database or add space to a database—exist on the devices that are available in the master.dbo.sysusages table, which lists disk pieces by database ID, starting logical page number, size in logical pages, device ID, and starting offset in the device.
If the specified to page is less than the from page, the pages are switched—that is, the to page becomes the from page, and vice versa. If from and to name the same page, the command affects only the allocation unit containing that page. The command does not adjust the to page in a way that causes a command error.
The entire device is affected if you do not provide any clauses. This is equivalent to log offdevice from 0. This command specifies physical storage, removing every log page on the specified device from the database:
alter database sales_db log off mylogdev
If alter database detects an error, it does not execute, and returns a message indicating the reason, such as:
The database log becomes too small.
The fragments to be removed contain pages that are allocated to syslogs. That is, the active log occupies space in the log fragments to be removed.
The amount of log free space after the fragment is removed is too small to accommodate the last chance threshold.
To see the names, sizes, and usage of device fragments already in use by a database, execute sp_helpdb dbname.
To see how much space the current database is using, execute sp_spaceused.
The system and default segments are mapped to each new database device included in the on clause of an alter database command. To unmap these segments, use sp_dropsegment.
When you use alter database (without override) to extend a database on a device already in use by that database, the segments mapped to that device are also extended. If you use the override clause, all device fragments named in the on clause become system/default segments, and all device fragments named in the log on clause become log segments.
If user processes are suspended because they have reached a last-chance threshold on a log segment, use alter database to add space to the log segment. The processes awaken when the amount of free space exceeds the last-chance threshold.
If you enter the for proxy_update clause with no other options, the size of the database is not extended; instead, the proxy tables, if any, are dropped from the proxy database and re-created from the metadata obtained from the path name specified during create database ... with default_location = ‘pathname’.
If you use alter database with other options to extend the size of the database, the proxy table synchronization is performed after the size extensions are made.
for proxy_update provides the database administrator with an easy-to-use, single-step operation with which to obtain an accurate and up-to-date proxy representation of all tables at a single remote site.
Resynchronization is supported for all external data sources, not just the primary server in a high availability-cluster environment. Also, a database need not have been created with the for proxy_update clause. If a default storage location has been specified, either through create database or with sp_defaultloc, the metadata contained within the database can be synchronized with the metadata at the remote storage location.
To make sure databases are synchronized correctly so that all the proxy tables have the correct schema to the content of the primary database you just reloaded, you may need to run the for proxy_update clause on the server hosting the proxy database.
ANSI SQL – Compliance level: Transact-SQL extension.
The permission checks for alter database differ based on your granular permissions settings.
Granular permissions enabled |
With granular permissions enabled, for sybsecurity, you must be the database owner or have any of these privileges: own database (on sybsecurity) or manage auditing. For all other databases, you must be database owner or have the own database privilege (on the database). |
Granular permissions disabled |
With granular permissions disabled, you must be the database owner, a user with sa_role, or a user with sso_role (for sybsecurity). |
Values in event and extrainfo columns of sysaudits are:
Event |
Audit option |
Command or access audited |
Information in extrainfo |
---|---|---|---|
2 |
alter |
alter database |
|
Commands create database, disk init, drop database, load database
System procedures sp_addsegment, sp_dropsegment, sp_helpdb, sp_helpsegment, sp_logdevice, sp_renamedb, sp_spaceused