im new to sql server. One of the instance encounters a scenario it shows the transaction log full, and the database need to perform backup in order to solve the issue.
I want to replicate the scenario again to show there is potential that the transaction log would go full, and suggest my client to increase the transaction log space and grow factor. (The database is using Full recovery mode)
However, the scenario is unable to replicate whatever how demanding query executed (40000 deletion and then 40000 insertion, repeatedly), i found that the transaction log occupied space is just trembling by querying it
DBCC SQLPERF(LOGSPACE)
I expects the transaction log will grow continuously when executing bulk insertion and deletion (no backup or checkpoint is done between the query). But the fact is the log space isn't really behaved as expected.
I would like to know
-
when the db throw exception transaction log is full – is it due to the out of memory of harddisk storage? or is it due to log size is over the configured size?
-
why the operations of bulk insertion & deletion didn't reduce the log space, but its size behaves trembling(up and down in stead of continuous increase)?
Best Answer
It's likely that you've missed one of these two steps in your test setup:
Until you've taken a full backup, even if the database is set to use the full recovery model, it's still essentially using the Simple model. Here's a post where Paul Randal discusses the situation:
Misconceptions around the log and log backups: how to convince yourself
Since your question says "checkpoint is done between the query)", this second point is likely your issue.
To answer your other question:
See this related question on this site for a lot of details on that topic: Why Does the Transaction Log Keep Growing or Run Out of Space?
It could be that the disk is out of space, or the log can't grow because it's reached it's max size and is unable to grow anymore. Some solutions to this issue would be to take log backups more frequently, change to a different recovery model, increase the size of the disk where the log file resides, etc.'
Regarding a couple of comments on this answer:
and
The only way I know of to tell if a backup hasn't been performed since the DB was switch to full is to attempt a log backup. It will fail with the error "BACKUP LOG cannot be performed because there is no current database backup."
This really shouldn't be a problem in practice, since you're backing up real production databases, right? =P But in a test environment, I would just run this to see where things stand: