This section contains error messages for Adaptive Server dump and load commands.
17
Unable to continue logged version of DUMP TRAN. No space left in database; use NO_LOG option or run ALTER DATABASE. Else, an old transaction may be active; see Syslogshold table.
This error occurs when Adaptive Server runs out of space in the transaction log during a dump transaction command.
You have the following options for recovering from Error 4204:
If any old transactions are active, determine whether they can be terminated. If such transactions do exist and they can be terminated, then you can dump the transaction log, which may free up space in the database.
Perform a dump transaction with the no_log option. dump transaction with no_log removes the inactive part of the log without making a backup copy and without recording the procedure in the transaction log (performs a checkpoint).
Extend the transaction log segment.
Each of these options is described below.
In the master database, there is a table called syslogshold. This table contains information about each database's oldest active transaction (if any) and Replication Server truncation point (if any) for the transaction log. This table is built dynamically when you query it.
Check syslogshold for old transactions for the database for which the error occurred:
1> use master 2> go
1> select * from syslogshold 2> where dbid = database_ID 3> go
Determine whether the oldest active transaction can be terminated (perhaps it was left active unintentionally). If you can terminate this transaction and then execute a dump transaction with no_log command, space may be returned to the database. Continue this process until there are no other old transactions that can be terminated. If, after terminating some old transactions, you still get Error 4204, try one of the other options described in this writeup.
Use the following method to determine approximately how many pages the transaction log occupies:
1> use database_name 2> go
1> select data_pgs (8, doampg) 2> from sysindexes where id=8 3> go
where “8” is the ID for syslogs. The result is the number of data pages (2K pages on most operating systems) that the transaction log occupies.
The query results may be inaccurate by as many as 16
pages, but using the query is much faster than counting the rows
in the transaction log.
Dump the transaction log using the no_log option.
Repeat step 1. If the transaction log now occupies significantly fewer pages, continue with the next step now.
If, however, there are still a large number of pages in the syslogs table, an outstanding transaction is probably preventing the log from being cleared. If this is the case, do one of the following:
Follow the instructions in “How to Detect and Clear Long-Running Transactions” in the Encyclopedia of Tasks chapter.
Restart Adaptive Server and repeat step 2. When Adaptive Server starts and this database is recovered, the outstanding transaction is rolled back, allowing the log to be cleared by a subsequent dump transaction.
Dump the database now, because the no_log option prevents subsequent changes recorded in the log from being used to recover from a media failure. You must do a dump database now to ensure the recoverability of subsequent database modifications using transaction logs.
This database dump is not required if your backup and
recovery procedures do not include saving the transaction logs for
media failure recovery.
If you are concerned that your transaction log is not large enough for your Adaptive Server, refer to information about estimating the transaction log size within “Creating and Managing User Databases” in the System Administration Guide before deciding to increase its size. If you choose to increase the size, refer to the Adaptive Server Reference Manual for more information about the alter database command used to increase log size. Remember that once they have been increased, log and database sizes cannot be decreased.
WARNING! If you use this option to extend the transaction log segment, you will not be able to get that space back later.
Refer to “Estimating the Transaction Log Size” within “Creating and Managing User Databases” in the System Administration Guide before deciding whether to increase the transaction log size.
To get information about the log segment, enter a command like the following and replace “test” with the name of the database in the error message:
1> use test 2> go
1> sp_helpsegment logsegment 2> go
segment name status ------- ------------------------------ ------ 2 logsegment 0
device size free_pages ------------------------------ ---------------------- ---------- dev1 1.0MB 512
table_name index_name indid --------------------------- ----------------------------- ------ syslogs syslogs 0
If you have more space in the current log device fragment, increase the amount of space allocated for the transaction log with commands like the following:
1> use master 2> go
1> alter database database_name 2> log on device_name = additional_space 3> go
where:
database_name is the name of the database for which the log device fragment is to be extended.
device_name is the name of the database device on which to locate the database extension.
additional_space is the number of megabytes to extend the log device fragment.
If you do not have any more space in the current log segment, you can use sp_extendsegment to extend the range of the log segment to another database device (the database must already exist on that device fragment before you run these commands):
1> use database_name 2> go
1> sp_extendsegment logsegment, database_name, 2> device_name 3> go
where:
database_name is the name of the database where the segment is to be extended.
device_name is the name of the additional database device for the log segment.
WARNING! If you use sp_extendsegment to extend the range of the log segment to another database device and the other device contains data, the segment on which that data exists will become a log segment. This situation can cause you to run out of space in the database earlier than you expected and may cause other problems, including 2558 errors.
All versions
16
Syslogs does not exist in its own segment in database ’%S_DBID’ with segmap ’%ld’ with logical start page number of ’%ld’. You cannot use DUMP TRANSACTION in this case, use DUMP DATABASE instead.
The dump transaction command copies the transaction log, which resides in the syslogs table, recording any database changes made since the last database dump or transaction log dump. Error 4205 is raised when you attempt dump transaction, but the log and data share the same device. Transaction log dumps are only possible when data and log reside on separate devices.
Since transaction logs are used for up-to-date recovery in the event of a disk failure, they are useful only if kept separate from the data device.
Use dump database. This will make a copy of the entire database, including both data and the transaction log.
Unless you are creating small, noncritical databases, always place the log on a separate device. This allows you to dump transaction logs, ensures full recovery from hard disk crashes and has many other benefits including performance improvement. For details, refer to Placing the Transaction Log on a Separate Device in the System Administration Guide.
When data and log share device space, it is possible to move the transaction log to its own device by using the system stored procedure sp_logdevice. For related information, see the writeup for Error 4222 in this manual.
All versions
16 State 2
Dump transaction is not allowed because a non-logged operation was performed on the database. Dump your database or use dump transaction with truncate_only until you can dump your database.
This error occurs when you have performed a minimally logged operation such as bcp in or select into on the database, followed by a dump transaction to a dump device. The dump transaction is not allowed because your database contains data that cannot be recovered from the log. The log could not be used to recover the database properly. For instance, if a user does a select into followed by an update, data for the select into is not recorded in the log, so the update cannot be recovered from the log.
A minimally logged operation is one in which changes
to the data itself are not logged to the transaction log. All changes
to the allocation structures resulting from the operation are logged
to the transaction log.
Note that simply enabling the select into / bulkcopy option does not, in itself, cause this condition. The option must be set and a minimally logged operation executed before this error message is reported during a dump transaction to a dump device.
Dumping the database creates a new save point on which subsequent transaction logs are based. Therefore, dumping the database ensures that the minimally logged changes are recoverable and dumping the transaction log to a device is once again allowed.
Perform a dump database. Disabling the select into/bulkcopy option using sp_dboption will not allow you to dump the log. You must dump the database to clear the 4207 error condition. You may want to disable the select into/bulkcopy option to prevent any further nonlogged operations in your database.
You may need to use dump transaction with truncate_only until you can perform a full database dump. If you must do this, you will lose the ability to recover up-to-the-minute changes in data in case of a media failure.
All versions
21
%s failed in database %.*s: unexpected end of log encountered on page %ld while scanning for page %ld.
This error may be caused by a hardware problem.
The transaction log consists of a series of log pages chained together in a doubly linked list; each log page has a page header with pointers to the next and previous log pages. The previous page pointer for the first page is zero, as is the next page pointer for the last page, indicating the beginning and end of the log chain respectively.
Error 4216 is raised when Adaptive Server finds what it considers to be a premature end of the transaction log chain during execution of a command. This error is raised during dump transaction or dump database and is often seen in conjunction with Error 4219.
Error 4216 can be caused by a bad page chain or allocation (syslogs corruption).
Determine the status of syslogs:
1> use database_name 2> go
1> dbcc checktable (syslogs) 2> go
1> dbcc tablealloc (syslogs) 2> go
where database_name is the name of the database appearing in the error message.
dbcc reports any problems found in syslogs, and the number of data pages being used by the log. If your log is on a separate device, dbcc checktable also tells you how much space is used and how much is free.
If no problems were reported, the transaction log is clean. Call Sybase Technical Support for assistance.
If problems were reported, try to fix them using the sections in this manual that describe those errors. If errors are still reported, call Sybase Technical Support.
For information about estimating and managing the transaction log size, refer to “Creating and Managing User Databases” in the System Administration Guide.
Before calling Technical Support, have the following information available:
Server version and SWR Rollup level
Server error log
Output of dbcc checktable and dbcc tablealloc
Text of all error messages
11.0 and higher
16
DUMP TRANsaction to a dump device is not allowed where a truncate-only transaction dump has been performed after the last DUMP DATABASE. Use DUMP DATABASE instead.
The dump database command makes a copy of the entire database, including both the data and the transaction log. dump database does not truncate the log.
The dump transaction command copies the transaction log, recording any database changes made since the last database or transaction log dump. After copying the log, it truncates the inactive portion. The dump transaction with truncate_only command, on the other hand, removes transactions from the log without making a backup copy.
Error 4221 occurs in the following situations:
If you attempt a dump transaction command, and the most recent dump consisted of a dump transaction with truncate_only. This is not allowed because the dump transaction would produce a transaction dump that could not be applied, since the prior dump transaction with truncate_only removed transactions upon which the current transactions may depend. To ensure recoverability, you must dump the database with dump database each time it is necessary for you to run a dump transaction with truncate_only command.
If you use the log on clause to create database to place the transaction log on a separate database device, and you attempt a dump transaction prior to dumping the database.
Perform a dump database first to back up the database and log. Follow this up with the appropriate dump transaction command.
Make sure the trunc log on chkpt database option is off. When this option is on you cannot dump the transaction log.
All versions
16
DUMP TRANSACTION for database '%S_DBID' failed: log page (%ld) is on a data-only segment. This is probably due to an incomplete move of the log to a device separate from the data. Complete the log migration or contact the System Administrator.
The dump transaction command copies the transaction log, recording any database changes made since the last database dump or transaction log dump. After copying, it truncates the inactive portion of the log. Transaction log dumps are only possible when data and log reside on separate devices.
If data and log share device space, it is possible to move the transaction log to its own device by using the system stored procedure sp_logdevice.
Error 4222 is raised when you execute dump transaction, but the first page of the transaction log is found to be on a data-only segment of the database. Since the log is not isolated from the data, the transaction dump fails.
The likely cause of this error is that the steps to move the log to a separate device were initiated, but were not complete at the time you issued dump transaction. To understand this, note that sp_logdevice moves future allocation for the transaction log to the new device. However the log remains on the original device until the extent that is currently in use has been filled and the transaction log has been dumped. Error 4222 indicates that the log in its current state cannot be migrated to its own device.
Take the following steps to resolve the error:
Run dbcc checktable (syslogs) to determine which page is currently in use.
Execute enough transactions to fill the extent currently in use. The following commands will fill at least one extent on the log (8 pages):
1> create table dummy1 (c1 char(255), c2 char(255)) 2> go
1> insert dummy1 values ("a", "a")
2> go 16
1> drop table dummy1 2> go
Make sure that there are no currently active transactions on the database device, then run dump transaction with truncate_only.
If an active transaction causes a begin tran to
be written onto the log pages in question, a transaction dump will
not be able to truncate those pages. This is why you should avoid
having activity on the device while you migrate the log off the
data segment.
Run the system procedure sp_helplog to ensure that the complete log is on the new device.
Refer to the System Administration Guide for details on moving the transaction log to another device.
All versions
16
Specified file '%.*s' is out of sequence. Current time stamp is %S_DATE while dump was from %S_DATE.
During a load transaction, Adaptive Server checks the timestamp on the dumped database and each dumped transaction log to determine whether the sequence is correct. If the load sequence of the transaction logs is incorrect, Error 4305 occurs and the load fails.
If you are missing a transaction log dump, you can only restore up to the transaction log dump before the missing dump.
In addition, you cannot load multiple transaction log dumps that have been created with the no_truncate option. The no_truncate option assumes that nothing further will be done with the transaction log after that point: it is only useful for up-to-the-minute recovery of a database after failure of the data device. If you have used the no_truncate option and your database is still okay, do a dump database as soon as possible.
This error is serious as the load processing stops and the load transaction fails.
Load the log backups in the same sequence in which they were made. Check your transaction log dumps to determine whether one was loaded out of order. If you find the correct dump, load it and continue with the rest of the dumps, in order.
For more information, refer to “load transaction” in the Reference Manual.
All versions
16
SQL Server cannot load a dump of the master database that was dumped from an older version of SQL Server. The current master database upgrade version is %ld, the dump master database upgrade version is %ld.
Error 4322 is raised when you try to load a dump of the master database that was created on an earlier version of Adaptive Server than your currently installed version.
If you know you do not have a dump of master from your current version level because you did not dump master after you upgraded, and your master database is corrupted, call Sybase Technical Support.
Otherwise, check the current upgrade version of the master dump you are trying to load. For example:
1> load database master from 'master.dump' with headeronly 2> go
Backup Server session id is: 6. Use this value when executing the `sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name `master_952820A2F8' section number 0001 mounted on disk file `/remote/solaris/rel1100/install/master.dump'
This is a database dump of database ID 6, name `master', from Oct 9 1995 11:35AM. SQL Server version: SQL Server/11.0/B/Sun_svr4/OS5.2/1/OPT/Fri Aug 1805:10:26 PDT 1995. Backup Server version: Backup Server/11.0/B/Sun_svr4/OS5.4/1/OPT/Thu Aug 17 21:54:21 PDT 1995.
Database contains 1536 pages; checkpoint RID=(Rid pageid = 0x405; row num = 0xd); next object ID=3031; sort order ID=50, status=0; charset ID=1.
Database log version=2; database upgrade version=1.
The log version and upgrade version have values as follows:
Version |
Value Is 0 |
Value Is 1 |
Value Is 2 |
|---|---|---|---|
Database log version |
10.0.x or earlier |
10.1 |
11.0 or later |
Database upgrade version |
10.x or earlier |
11.0 or later |
Not used |
If you need to call Sybase Technical Support, have the following information ready:
Server version and SWR Rollup level
Server error log
Text of all error messages
Output from load database...with headeronly command if you have what you thought was a current dump
Output from sp_configure "upgrade version"
All versions
