[quoted text, click to view] In article <1153346264.423599.313110@p79g2000cwp.googlegroups.com>, "Damon" <damonf@cox.net> wrote:
>
>Kayda wrote:
>> Hi:
>>
>> I have a database table I have designed with a row size of 0.35 KB. Is
>> it possible to calculate the approximate log file size (or at least the
>> portion attributable to this table) if I know the amount of rows I will
>> be inserting into this table every day? (a one time insert nightly)
>>
>> Thanks,
>> Kayda
>
>Kayda,
>
>Why do you need to know the size of the log file?
>
>The log file will change in size depending on the amount of information
>that SQL has to store in case of a rollback of any kind. This
>information is deleted as it becomes obsolete. I do not know of a good
>way to calculate the size of the log file. The log file shouldn't be
>very large and if it is then there are ways to fix it. Have you tried
>shrink the database. Sometimes you can detach the database then move
>the log file to another location then re-attach the DB. Most of the
>time it will create a new log file of 1K.
>
>Hope this helps.
>Damon.
>
Unless, of course, you have some sort of a nightly process that dumps a large
number of recrds in, between log file backups.
Kayda, Damon is right on a long term basis. Your Transaction Log backups will
empty the log. The maximum size of your log file will be size of the maximum
number of transaction s that occur between backups, plus the asociated changes
to any indexes. As a simple rule of thumb, without indexes; if you dump 3000
.3k records in, your log file will contain a smidge over 1000k. Indexes will
add to this according to their size.
If this is a regular thing, I'd suggest turning on auto grow and leaving auto
shrink off. After you've run the process a couple of days, you can increase
the size by enough that you're comfortable, then turn off the auto grow, if
