Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2000-09-13 : 21:35:10
|
Gary writes "I recently submitted a question to you looking for why Backup Log ... with no_truncate
does not work in SQL Server 7.0.
After much research and some testing I learned the answer to my question and wanted to
share it with you for the benefit of one and all. Answer follows:
SQL Server 7.0
Date 8/14/00
Introduction to the "Backup Log ...with no_truncate" feature of SQL Server 7.0.
On occasion a database may become corrupt or a database file may be inaccessible. Ideally, in these cases you want to be able to restore and recover the data back to the current point in time.
This requires that the Transaction Log be backed up prior to the restore process beginning.
Microsoft has provided the "Backup Log ...with no_truncate" feature for use in cases such as this. However, this feature works only under very specific conditions and thus is the topic of this document.
Background.
When a database is defined, it always has a primary file group. In some cases this may be the only file group defined for the database. The primary filegroup contains, at a minimum, the system tables for the database being defined. The systems tables hold metadata describing the database. Where no other filegroups have been defined, the primary file group will also contain the user defined tables/indexes.
Essential requirement
"Backup Log Â…Â… with no_truncate" must be able to access the "metadata" located in the primary file group, or it will not work. This also means that this part of the database must not be corrupt or that the file containing this part of the database must not be inaccessible.
Specific conditions required for "Backup Log Â….. with no_truncate" to work.
a. The database needs to be defined so that the user tables/indexes are contained in one or more file groups other than the primary filegroup.
b. Logging of changes to the database must be in effect.
c. A full backup must exist
d. Changes are made (logged) to the user database.
e. No non-logged operations must have been performed since the last full backup.
f. The primary filegroup file(s) must be available.
g. The primary filegroup data must not be corrupted. Or at least the portion needed by the backup operation must not be corrupted. I am not 100% sure about this issue.
h. The data in the filegroups other than primary may be corrupted or these files may be completely missing.
Process to restore/recover.
a. When problem detected (data file(s) inaccessible or database is corrupted), if primary filegroup is accessible, then perform the Backup Log Â…. with no_truncate.
b. Then perform the restore process using the "with replace" option for the database. This will get back any missing file(s) and recover you right up to when the last log backup was taken.
c. Post restore/recover process, your database will not be corrupt or missing any data file(s)
Bottom line
To achieve maximum recoverability, the following is recommended.
a. Define databases so that user data is not put in the primary file group.
i.e. Define not only a primary filegroup, but also one or more "other" filegroups.
b. Place user data in the "other" filegroup(s), NOT in the primary filegroup.
c. Place the primary filegroup on a disk drive separate from the "other" filegroup(s).
d. Place the log on a disk drive by itself.
Under the above scenario, at least three different disk drives would be needed to accommodate a single database.
Some sources recommend you put the primary file group and the transaction log on the same disk drive (mirrored). This would of course reduce the maximum number of disks needed to two. This topic, from my perspective, is another issue to be separately addressed and thus is not covered any further in this document.
Remember, even if the database files are iso |
|
|
|
|
|
|
|
Backup Log .... with no_truncate option does not work