good time to shrink TLog?

sql2k sp3
Ive got a db that I just created 3 days ago and already
the TLog is 5 gigs. I do a Full Backup at 2AM every day
and TLog backups every 5 minutes between 5:AM and 7:PM.
This is a replicated db. Every night before the Full
Backup we turn off replication, truncate 3 tables, bulk
insert new data into those tables, turn on replication.
(Of course that explains the big TLog.) The only way I can
get the size of the TLog down by a signifigant amount is
to do a "backup log with truncate_only" followed by
shrinking the file. Does anyone know, based on this
scenario, when a good time to do this stuff is? I tried
only doing the shrink part but it didnt reduce the size a
whole lot. Is there another way to go about this?
Thanks.Chris
I'm finding some of the things you are doing a little hard
to understand, but that may be due to not having all the
info. What are you using replication for? It seems strange
to turn it off, do some major changes to your database and
then turn it back on. Do you not replicate those changes?
Are you doing a database snapshot following the work? How
are you keeping you databases in line with this process?
One possible solution for your actual problem, depending
on disk space and DR strategy, would be to take a full
backup before the changes, go to simple recovery mode.
Perform the changes. Switch back to full recovery after
the changes and take another full backup. This should cut
down on the growth to your transaction log.
I think a better understanding of your replication usage
may lead to a better solution.
Regards
John|||What are you using replication for? It seems strange
>to turn it off, do some major changes to your database
and
>then turn it back on.
So our client can access this data. I need to turn off
replication because I need to truncate these table @. night.
Do you not replicate those changes?
>Are you doing a database snapshot following the work?
Yes. These tables are in their own Publication and it gets
re-snapshotted every night.
How
>are you keeping you databases in line with this process?
Not sure I get this one?
So do you know of a good time I could truncate and shrink
the log?
>--Original Message--
>Chris
>I'm finding some of the things you are doing a little
hard
>to understand, but that may be due to not having all the
>info. What are you using replication for? It seems
strange
>to turn it off, do some major changes to your database
and
>then turn it back on. Do you not replicate those changes?
>Are you doing a database snapshot following the work? How
>are you keeping you databases in line with this process?
>One possible solution for your actual problem, depending
>on disk space and DR strategy, would be to take a full
>backup before the changes, go to simple recovery mode.
>Perform the changes. Switch back to full recovery after
>the changes and take another full backup. This should cut
>down on the growth to your transaction log.
>I think a better understanding of your replication usage
>may lead to a better solution.
>Regards
>John
>.
>|||Chris
Is my suggestion to change the recovery mode during the
busy period not an option then? That way you should not
need to shrink the log. Whilst it may not always possible,
I would like to set up systems so your database and tlog
are the correct size and don't require shrinking. It's not
a good practice to perform regular shrinks.
Just a thought, are you perfomrning regular tlog backups?
By the way how big is your database?
Regards
John