Attaching and Detaching Databases Microsoft® SQL Server™ allows the data and transaction log files of a database to be detached and then reattached to another server, or even to the same server. Detaching a database removes the database from SQL Server, but leaves the database intact within the data and transaction log files that compose the database. These data and transaction log files can then be used to attach the database to any computer running SQL Server, including the server from which the database was detached. This makes the database available in exactly the same state it was in when it was detached.
Detaching and attaching databases is useful if you want to move a database:
From one computer to another without having to re-create the database and then restore the database backup manually. To a different physical disk, for example, when the disk containing the database file has run out of disk space and you want to expand the existing file rather than add a new file to the database on the other disk. To move a database, or database file, to another server or disk:
Detach the database. Move the database file(s) to the other server or disk. Attach the database specifying the new location of the moved file(s). When attaching a database, the name and physical location of the primary file must be specified. Because the primary file contains the information needed to find the other files comprising the database, it is necessary to specify only the location of the files that have changed location, for example, files originally located on the C:\\Mssql7\\Data subdirectory that are now located on the D:\\Mssql7\\Data subdirectory. Any files that have changed location must be specified. Otherwise, SQL Server will try to attach the files based on the file location information stored in the primary file. If the files have changed location, they will not be found, and the database will not be successfully attached.
When you say \"slet\" do you mean empty or remove? There is a BIG difference! Each database has a log (dlf) file which you just cant REMOVE. It can be TRUNCATED.
Truncating the Transaction Log If log records were never deleted from the transaction log, the log would keep growing until it filled all the available space on the disks holding the log. At some point in time, old log records no longer necessary for recovering or restoring a database must be deleted to make way for new log records. The process of deleting these log records is called truncating the log.
The active portion of the transaction log can never be truncated. The active portion of the log is the part of the log needed to recover the database at any time. It must always be present in the database in case the server fails because it will be required to recover the database when the server is restarted. The record at the start of the active portion of the log is identified by the minimum recovery log sequence number (MinLSN).
The backup and restore process chosen for a database determines how much of the transaction log in front of the active portion must be retained in the database. While the log records in front of the MinLSN play no role in recovery, they are required to roll forward updates when using log backups to restore a database to the point of failure.
The log records before the MinLSN are only needed to maintain a sequence of log backups. If a log backup sequence is not being maintained, all log records before the MinLSN can be truncated at any time. If a log backup sequence is being maintained, the part of the log before the MinLSN cannot be truncated until those log records have been copied to a log backup.
If a database log backup sequence is not being maintained for a database, the database can be set into log truncate mode. The trunc. log on chkpt. database option must be set to TRUE for a database to be eligible for log truncate mode. Whether the database is actually in log truncate mode also depends on the state of the database:
The database comes out of log truncate mode when a BACKUP DATABASE statement is executed. This is because a BACKUP DATABASE statement is the starting point of a log backup sequence. The database remains out of log truncate mode until an event that invalidates the log backup sequence occurs. These events are: A BACKUP LOG statement is executed that references the database and specifies either the NO_LOG or TRUNCATE_ONLY options. A nonlogged operation is performed in the database, such as a nonlogged bulk copy operation or a nonlogged WRITETEXT statement. An ALTER DATABASE statement that adds or deletes a file in the database is executed. When in log truncate mode, the database remains in log truncate mode until either a DUMP DATABASE statement is executed or the trunc. log on chkpt. option is set to FALSE. A log backup sequence cannot be maintained for a database that is in log backup mode. The only BACKUP LOG options that are valid for a database in log backup mode are the NO_LOG or TRUNCATE_ONLY options.
Does this mean that I have to placed the database in truncate mode and then backup the database. After this operation the database wil start on a new log.dlf file?
It is not possible to backup the database maybe because the database is full and the database is full because of the log file. Is this a catch 22? I will double you points on this one....
Ok, i have made a backup by selecting another path to another disk but this truncation does not work! Why - my log is still 46 gb - i\'m glad that I didn\'t make this maintenance plan...
lkhlars>Did you solve the problem? Sorry for not getting back as I said I would!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.