A single transaction log file has both a physical size (that you see on disk), and it's also broken down within the physical file into logical sections called virtual log files (VLFs).
Both auto-growth and auto-shrink operate on the physical transaction log file.
Transaction log truncation (also called "log clearing") operates on the logical sections of the transaction log (VLFs), and does not affect the physical file size. This part is frequently the subject of confusion.
A log file must always grow to accomodate a large transaction; turning off auto-shrink will leave the log file with its maximum needed size, instead of physically decreasing its size.
If you don't have large transactions, it will be safe to disable auto-shrink; the log files will not grow without bound like would happen if the database was in FULL
or BULK_LOGGED
and you weren't taking transaction log backups.
This behaviour is the same for SQL Server 2005+.
Just to complement or add to the other answer
there are times you get a really hairy message
first thing I do is to turn on the verbose:
Turn on verbose history (Replication monitor->Agent Profile->Verbose History) and use the -output parameter and select a destination for the output file (Subscriber Replication Job -> Edit Run Agent Job -> In the command window add -output C:\MyFilePath\FileName.log).
and:
Have a look at the latest part of the command below, you see the output parameter.
-Publisher [TCP-ODS01] -PublisherDB [concord_ods] -Publication [MERLIN_PUBLICATION] -Subscriber [MERLIN771] -SubscriberDB [ConCORD_ODS] -Distributor [TCP-MERGE01] -DistributorSecurityMode 1 -HostName [MERLIN771] -output C:\Replication\MERLIN771_1132.log
Now we can have a look at the log file.
Now you can have a look on the log generated and proceed from there.
Example (see the next picture below):
The command on the job is:
--This is the MERLIN307 subscriber, I am troubleshooting, outputting to the log at c:\replication and using the - VerbatimTextObjectScripting 0 option.
-Publisher [TCP-ODS01] -PublisherDB [concord_ods] -Distributor [TCP-MERGE01] -Publication [MERLIN_PUBLICATION] -ReplicationType 2 -DistributorSecurityMode 1 -DynamicFilterHostName [MERLIN307] -DynamicSnapshotLocation [\\TCP-MERGE01\REPLDATA\\unc\TCP-ODS01_CONCORD_ODS_MERLIN_PUBLICATION\MERLIN307_9\] -PartitionId 9 -VerbatimTextObjectScripting 0 -output C:\Replication\MERLIN307-983.log
I can't really give you a straight answer to your case in particular, but I can definitely help you finding out what the problem is, using these steps above.
If it sounds confusing, drop a comment below I will try to be more specific.
Best Answer
I've not tried fn_dblog on Express but if it is available the following will give you delete operations:
Take the transaction ID for transactions you're interested in and identify the SID that initiated the transaction with:
Then identify the user from the SID:
Edit: Bringing that all together to find deletes on a specified table: