Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I can't imagine why a simple SELECT statement would add anything to the transaction log, but I don't have a lot of experience with linked servers, so I can't say for sure what might be happening behind the scenes.</p> <p>However, you say "Database B has some views and procs which are constantly accessing and updating data in database A.", so even though the underlying data exists on Database A, because your new application connects to database B and uses it's objects, it seems reasonable that those operations are recorded in B's tran log. </p> <p>But that's just conjecture on my part. Why don't you just inspect the transaction log directly and see if what it contains seems reasonable? RedGate has a free log explorer that works with SQL 2000 (see <a href="http://www.red-gate.com/products/SQL_Log_Rescue/index.htm" rel="nofollow noreferrer">http://www.red-gate.com/products/SQL_Log_Rescue/index.htm</a>); I've only used it once before, but it seemed to work well and it really saved my bacon in that particular instance.</p> <p>I'll admit that I'm curious about the details, but in your situation I'd be tempted to suppress my curiosity and just deal with the log file. After all, this is just temporary, and if the log growth is an artifact of the linked servers it should fix itself once you finish the new app and retire Database A.</p> <p>Also, Godeke made a good point about backups. If your log file is growing too large, then back it up more often. Backing it up truncates the log, but only internally; i.e. the percentage of the log file used will shrink, but the actual size of the file on disk won't change until you use DBCC SHRINKFILE to do so.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload