A couple LDF questions.

I do a bit a sql programming but do not handle the admin side. Our
server backups are becoming huge so I looked around to see why. A
couple of our databases (small... ~60Megs) have ldf files that are
almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
shows that there are almost 200 virtual logs in each ldf file, all
with active transactions. One of these databases is still attached but
hasn't been used for over a year. How can I determine more information
about these transactions, or force old ones to close? Our datacenter
handles the actual scheduled backups so I don't really want to mess
with too much but i'm hoping there's a way for me to shrink the log
size to something more 'appropriate' without losing any necessary
information. Is this something that they (datacenter) should handle
(they don't manage our databases, just the backups) or is this likely
to be a software issue not closing the transactions so they persist?
Any thoughts or comments greatly appreciated.
Thanks.
Mark<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegroups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
>
My guess is that they are NOT handling backups correctly. Sounds like they
may not be doing a transaction log backup.
Try DBCC opentran on each database. This should return the SPIDs of any
open transactions.
dbcc inputbuffer(spid)
and
sp_who2 spid
to find out what they are doing.
You might be able to kill the spids.

> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||As Greg mentioned, you have probably missed doing log backups for the databa
se. If the db is in full
recovery mode, and you don't do log backups, then the log file is never "emp
tied". Or, in other
words, the virtual log file will have a status of 2. If you don't want to do
log backups, you should
set the database to simple recovery mode.
I also want to point out that status 2 is not the same as open transactions.
It just mean that the
virtual log file cannot be re-used, because you haven't done a log backup ye
t.
Some more info at http://www.karaszi.com/SQLServer/info_dont_shrink.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegroups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>|||many thanks to both. that helps. i'll try the code to learn more about
the spid's and will call the datacenter to see what the backup
settings are. thanks again.

A couple LDF questions.

I do a bit a sql programming but do not handle the admin side. Our
server backups are becoming huge so I looked around to see why. A
couple of our databases (small... ~60Megs) have ldf files that are
almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
shows that there are almost 200 virtual logs in each ldf file, all
with active transactions. One of these databases is still attached but
hasn't been used for over a year. How can I determine more information
about these transactions, or force old ones to close? Our datacenter
handles the actual scheduled backups so I don't really want to mess
with too much but i'm hoping there's a way for me to shrink the log
size to something more 'appropriate' without losing any necessary
information. Is this something that they (datacenter) should handle
(they don't manage our databases, just the backups) or is this likely
to be a software issue not closing the transactions so they persist?
Any thoughts or comments greatly appreciated.
Thanks.
Mark
<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegr oups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
>
My guess is that they are NOT handling backups correctly. Sounds like they
may not be doing a transaction log backup.
Try DBCC opentran on each database. This should return the SPIDs of any
open transactions.
dbcc inputbuffer(spid)
and
sp_who2 spid
to find out what they are doing.
You might be able to kill the spids.

> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||As Greg mentioned, you have probably missed doing log backups for the database. If the db is in full
recovery mode, and you don't do log backups, then the log file is never "emptied". Or, in other
words, the virtual log file will have a status of 2. If you don't want to do log backups, you should
set the database to simple recovery mode.
I also want to point out that status 2 is not the same as open transactions. It just mean that the
virtual log file cannot be re-used, because you haven't done a log backup yet.
Some more info at http://www.karaszi.com/SQLServer/info_dont_shrink.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegr oups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>
|||many thanks to both. that helps. i'll try the code to learn more about
the spid's and will call the datacenter to see what the backup
settings are. thanks again.

A couple LDF questions.

I do a bit a sql programming but do not handle the admin side. Our
server backups are becoming huge so I looked around to see why. A
couple of our databases (small... ~60Megs) have ldf files that are
almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
shows that there are almost 200 virtual logs in each ldf file, all
with active transactions. One of these databases is still attached but
hasn't been used for over a year. How can I determine more information
about these transactions, or force old ones to close? Our datacenter
handles the actual scheduled backups so I don't really want to mess
with too much but i'm hoping there's a way for me to shrink the log
size to something more 'appropriate' without losing any necessary
information. Is this something that they (datacenter) should handle
(they don't manage our databases, just the backups) or is this likely
to be a software issue not closing the transactions so they persist?
Any thoughts or comments greatly appreciated.
Thanks.
Mark<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegroups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
>
My guess is that they are NOT handling backups correctly. Sounds like they
may not be doing a transaction log backup.
Try DBCC opentran on each database. This should return the SPIDs of any
open transactions.
dbcc inputbuffer(spid)
and
sp_who2 spid
to find out what they are doing.
You might be able to kill the spids.
> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>
--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||As Greg mentioned, you have probably missed doing log backups for the database. If the db is in full
recovery mode, and you don't do log backups, then the log file is never "emptied". Or, in other
words, the virtual log file will have a status of 2. If you don't want to do log backups, you should
set the database to simple recovery mode.
I also want to point out that status 2 is not the same as open transactions. It just mean that the
virtual log file cannot be re-used, because you haven't done a log backup yet.
Some more info at http://www.karaszi.com/SQLServer/info_dont_shrink.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<mark_s_nospam@.entouch.net> wrote in message
news:1176998140.170272.148150@.y80g2000hsf.googlegroups.com...
>I do a bit a sql programming but do not handle the admin side. Our
> server backups are becoming huge so I looked around to see why. A
> couple of our databases (small... ~60Megs) have ldf files that are
> almost 1 gig. I did some reading and learned about 'dbcc loginfo'. It
> shows that there are almost 200 virtual logs in each ldf file, all
> with active transactions. One of these databases is still attached but
> hasn't been used for over a year. How can I determine more information
> about these transactions, or force old ones to close? Our datacenter
> handles the actual scheduled backups so I don't really want to mess
> with too much but i'm hoping there's a way for me to shrink the log
> size to something more 'appropriate' without losing any necessary
> information. Is this something that they (datacenter) should handle
> (they don't manage our databases, just the backups) or is this likely
> to be a software issue not closing the transactions so they persist?
> Any thoughts or comments greatly appreciated.
> Thanks.
> Mark
>|||many thanks to both. that helps. i'll try the code to learn more about
the spid's and will call the datacenter to see what the backup
settings are. thanks again.

7.0 to 2000 Upgrade

Is this a reasonable way to upgrade a 7.0 server to 2000?
1. Backup the databases.
2. Move the database mdf and ldf files to a neutral
location on the server's drive.
3. Upgrade the server to Win 2k and Sql Server 2000.
4. Add pertinent logins.
5. Reattach the mdf and ldf files and let sql server
upgrade the databases "on the fly".
The reason I'm asking is that I've always been ultra-safe
in times past and used the copy wizard to copy my 7.0
databases to a 2000 server first.
Is an attach/reattach considered a supported way of doing
a 7.0 to 2000 conversion?
I'm a little scared of course because if it doesn't attach
for some reason, then I can try the .BAK files and if that
doesn't work, I'm dead.It is hard to find documentation that provides it one way or another.
However, iny my experience of doing it Attach/reattaching works fine. Just
make sure you have a backup copy of your databases becauase you'll not be
able to reattach them to a SQL 7.0 server after attaching them to SQL 2000.
The only concerns I can think of have to do more with the sort order, which
would show up when people start to connect and use the system. SQL 2000
supports attaching databases with different sort orders, but some stored
procedures that create temp tables may have issues without having the
collation order specified for them. Only thorough testing will reveal a
problem like this.
My *safest method* is to use DTS to transfer the databases to another
server, then copy them back.
****************************************
***************************
Andy S.
MCSE NT/2000, MCDBA SQL 7/2000
andymcdba1@.NOMORESPAM.yahoo.com
Please remove NOMORESPAM before replying.
Always keep your antivirus and Microsoft software
up to date with the latest definitions and product updates.
Be suspicious of every email attachment, I will never send
or post anything other than the text of a http:// link nor
post the link directly to a file for downloading.
This posting is provided "as is" with no warranties
and confers no rights.
****************************************
***************************
"CLM" <anonymous@.discussions.microsoft.com> wrote in message
news:121bf01c3f57c$ec04e740$a501280a@.phx
.gbl...
> Is this a reasonable way to upgrade a 7.0 server to 2000?
> 1. Backup the databases.
> 2. Move the database mdf and ldf files to a neutral
> location on the server's drive.
> 3. Upgrade the server to Win 2k and Sql Server 2000.
> 4. Add pertinent logins.
> 5. Reattach the mdf and ldf files and let sql server
> upgrade the databases "on the fly".
> The reason I'm asking is that I've always been ultra-safe
> in times past and used the copy wizard to copy my 7.0
> databases to a 2000 server first.
> Is an attach/reattach considered a supported way of doing
> a 7.0 to 2000 conversion?
> I'm a little scared of course because if it doesn't attach
> for some reason, then I can try the .BAK files and if that
> doesn't work, I'm dead.
>

7.0 to 2000 Upgrade

Is this a reasonable way to upgrade a 7.0 server to 2000?
1. Backup the databases.
2. Move the database mdf and ldf files to a neutral
location on the server's drive.
3. Upgrade the server to Win 2k and Sql Server 2000.
4. Add pertinent logins.
5. Reattach the mdf and ldf files and let sql server
upgrade the databases "on the fly".
The reason I'm asking is that I've always been ultra-safe
in times past and used the copy wizard to copy my 7.0
databases to a 2000 server first.
Is an attach/reattach considered a supported way of doing
a 7.0 to 2000 conversion?
I'm a little scared of course because if it doesn't attach
for some reason, then I can try the .BAK files and if that
doesn't work, I'm dead.It is hard to find documentation that provides it one way or another.
However, iny my experience of doing it Attach/reattaching works fine. Just
make sure you have a backup copy of your databases becauase you'll not be
able to reattach them to a SQL 7.0 server after attaching them to SQL 2000.
The only concerns I can think of have to do more with the sort order, which
would show up when people start to connect and use the system. SQL 2000
supports attaching databases with different sort orders, but some stored
procedures that create temp tables may have issues without having the
collation order specified for them. Only thorough testing will reveal a
problem like this.
My *safest method* is to use DTS to transfer the databases to another
server, then copy them back.
--
*******************************************************************
Andy S.
MCSE NT/2000, MCDBA SQL 7/2000
andymcdba1@.NOMORESPAM.yahoo.com
Please remove NOMORESPAM before replying.
Always keep your antivirus and Microsoft software
up to date with the latest definitions and product updates.
Be suspicious of every email attachment, I will never send
or post anything other than the text of a http:// link nor
post the link directly to a file for downloading.
This posting is provided "as is" with no warranties
and confers no rights.
*******************************************************************
"CLM" <anonymous@.discussions.microsoft.com> wrote in message
news:121bf01c3f57c$ec04e740$a501280a@.phx.gbl...
> Is this a reasonable way to upgrade a 7.0 server to 2000?
> 1. Backup the databases.
> 2. Move the database mdf and ldf files to a neutral
> location on the server's drive.
> 3. Upgrade the server to Win 2k and Sql Server 2000.
> 4. Add pertinent logins.
> 5. Reattach the mdf and ldf files and let sql server
> upgrade the databases "on the fly".
> The reason I'm asking is that I've always been ultra-safe
> in times past and used the copy wizard to copy my 7.0
> databases to a 2000 server first.
> Is an attach/reattach considered a supported way of doing
> a 7.0 to 2000 conversion?
> I'm a little scared of course because if it doesn't attach
> for some reason, then I can try the .BAK files and if that
> doesn't work, I'm dead.
>|||If you are going to upgrade Windows, I'd recommend
reinstalling everything from scratch. Our experience with
Windows upgrading in place is that it works successfully
30% of the time or less. And if it fails, it can fail
really hard (blue screen on a system that will never boot
again, i.e., total data loss).
SQL Server upgrades (without upgrading the OS) usually
work. One thing you *MUST* do, however, is install the
latest MDAC prior to beginning the SQL Server upgrade.
If you are worried about the integrity of the databases or
their backups, be sure to do a DBCC CHECKDB on all your
databases before you start this. Fix any problems before
taking your backups or detaching.
Also, keep records of all the logical *and* physical file
names (including the disk drive letters/file paths) for
*every* database file! You might need to know these to
get a restore or attach to work. This information can be
recorded from your existing installation only as long as
the databases are still attached, so get it first.
Regarding one of your questions: Both the attach and
restore SQL operations will automatically convert a SQL 7
database to SQL 2000.
P.S. It isn't really necessary to detach the databases to
copy them. You can copy the files safely as long as SQL
Server is stopped.
--Scott
>--Original Message--
>Is this a reasonable way to upgrade a 7.0 server to 2000?
>1. Backup the databases.
>2. Move the database mdf and ldf files to a neutral
>location on the server's drive.
>3. Upgrade the server to Win 2k and Sql Server 2000.
>4. Add pertinent logins.
>5. Reattach the mdf and ldf files and let sql server
>upgrade the databases "on the fly".
>The reason I'm asking is that I've always been ultra-safe
>in times past and used the copy wizard to copy my 7.0
>databases to a 2000 server first.
>Is an attach/reattach considered a supported way of doing
>a 7.0 to 2000 conversion?
>I'm a little scared of course because if it doesn't
attach
>for some reason, then I can try the .BAK files and if
that
>doesn't work, I'm dead.
>.
>