Is Truncating Log commiting data the the actual DB?

Newbie question running SQL 2k
My last entry in the .mdb file was January and everything else has been
sitting in the Transaction log files. Everything works fine. I'm just
wondering if Truncating the logs mean I'm going to commit the data from the
log files to the .mdb file. So if I truncate and look in the .mdb file,
will I see all my entries up to the most current period?
Thanks!AFAIK you will not see the data in the datafile until it is commited. And SQ
L
Server will not truncate stuff that is not commited or saved (for example
with a log backup).
Truncating the log means, that you truncate the unused or unneccessary data
from the logfile that is not neccessary any more.
regards
Andreas
"Phillip Vong" wrote:

> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from th
e
> log files to the .mdb file. So if I truncate and look in the .mdb file,
> will I see all my entries up to the most current period?
> Thanks!
>
>|||Phillip,
The data in the transaction log files is committed to the database files not
long after the transaction is written to the log. There are a number of
factors to consider, but if nobody has changed anything since January it all
should be in the database by now.
Truncating the log is throwing away the transaction records that could be
used to recover in case of a failure. Actually, you almost never should
truncate. If you do not want the logs, change to the SIMPLE recovery model.
And make sure that you backup the database regularly.
The behavior of transaction logs is discussed under the backup and restore
strategy portions of the Books Online, so you need to familiarize yourself
with those. It is not too complicated.
RLF
"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from
> the log files to the .mdb file. So if I truncate and look in the .mdb
> file, will I see all my entries up to the most current period?
> Thanks!
>|||Russell, thanks for the update.
Can you tell me why the data in my tranaction log files has not committed to
the db files? You said "Shortly", but the last entry was 1/18/2007 in the
db file. Things are added to this db everyday by my user. Why are they all
staying in the transaction log file and not being committed. Can I force it
to commit some how? There are 1027 records in the log files and I want to
commit them to the db file. Will changing db to SIMPLE force it to commit
the data? I'm not going to lose what I have in the Log files am I?
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:%23Gnin2lYHHA.992@.TK2MSFTNGP02.phx.gbl...
> Phillip,
> The data in the transaction log files is committed to the database files
> not long after the transaction is written to the log. There are a number
> of factors to consider, but if nobody has changed anything since January
> it all should be in the database by now.
> Truncating the log is throwing away the transaction records that could be
> used to recover in case of a failure. Actually, you almost never should
> truncate. If you do not want the logs, change to the SIMPLE recovery
> model. And make sure that you backup the database regularly.
> The behavior of transaction logs is discussed under the backup and restore
> strategy portions of the Books Online, so you need to familiarize yourself
> with those. It is not too complicated.
> RLF
> "Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
> news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
>|||"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:uWxxX%23mYHHA.3984@.TK2MSFTNGP02.phx.gbl...
> Russell, thanks for the update.
> Can you tell me why the data in my tranaction log files has not committed
> to the db files? You said "Shortly", but the last entry was 1/18/2007 in
> the db file. Things are added to this db everyday by my user. Why are
> they all staying in the transaction log file and not being committed. Can
> I force it to commit some how? There are 1027 records in the log files and
> I want to commit them to the db file. Will changing db to SIMPLE force it
> to commit the data? I'm not going to lose what I have in the Log files am
> I?
Umm, how are you determining that things are NOT being committed?
If you do a select against inserted data, if you're seeing it, (and not
using read uncommitted) the data is definitely committed.
If you're basing your assumptions on FILE dates, then two things:
1) The file date on the file is the last time the file was OPENED or the
SIZE of it was changed.
So it sounds like you're looking at the file size of the MDF and assuming
nothing is committed since the data hasn't changed. This isn't really true.
2) If the size of the transaction log is GROWING, this means you're not
doing transaction log backups most likely. Which means your recovery plans
probably wont' be good.

>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com

Is Truncating Log commiting data the the actual DB?

Newbie question running SQL 2k
My last entry in the .mdb file was January and everything else has been
sitting in the Transaction log files. Everything works fine. I'm just
wondering if Truncating the logs mean I'm going to commit the data from the
log files to the .mdb file. So if I truncate and look in the .mdb file,
will I see all my entries up to the most current period?
Thanks!
AFAIK you will not see the data in the datafile until it is commited. And SQL
Server will not truncate stuff that is not commited or saved (for example
with a log backup).
Truncating the log means, that you truncate the unused or unneccessary data
from the logfile that is not neccessary any more.
regards
Andreas
"Phillip Vong" wrote:

> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from the
> log files to the .mdb file. So if I truncate and look in the .mdb file,
> will I see all my entries up to the most current period?
> Thanks!
>
>
|||Phillip,
The data in the transaction log files is committed to the database files not
long after the transaction is written to the log. There are a number of
factors to consider, but if nobody has changed anything since January it all
should be in the database by now.
Truncating the log is throwing away the transaction records that could be
used to recover in case of a failure. Actually, you almost never should
truncate. If you do not want the logs, change to the SIMPLE recovery model.
And make sure that you backup the database regularly.
The behavior of transaction logs is discussed under the backup and restore
strategy portions of the Books Online, so you need to familiarize yourself
with those. It is not too complicated.
RLF
"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from
> the log files to the .mdb file. So if I truncate and look in the .mdb
> file, will I see all my entries up to the most current period?
> Thanks!
>
|||Russell, thanks for the update.
Can you tell me why the data in my tranaction log files has not committed to
the db files? You said "Shortly", but the last entry was 1/18/2007 in the
db file. Things are added to this db everyday by my user. Why are they all
staying in the transaction log file and not being committed. Can I force it
to commit some how? There are 1027 records in the log files and I want to
commit them to the db file. Will changing db to SIMPLE force it to commit
the data? I'm not going to lose what I have in the Log files am I?
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:%23Gnin2lYHHA.992@.TK2MSFTNGP02.phx.gbl...
> Phillip,
> The data in the transaction log files is committed to the database files
> not long after the transaction is written to the log. There are a number
> of factors to consider, but if nobody has changed anything since January
> it all should be in the database by now.
> Truncating the log is throwing away the transaction records that could be
> used to recover in case of a failure. Actually, you almost never should
> truncate. If you do not want the logs, change to the SIMPLE recovery
> model. And make sure that you backup the database regularly.
> The behavior of transaction logs is discussed under the backup and restore
> strategy portions of the Books Online, so you need to familiarize yourself
> with those. It is not too complicated.
> RLF
> "Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
> news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
>
|||"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:uWxxX%23mYHHA.3984@.TK2MSFTNGP02.phx.gbl...
> Russell, thanks for the update.
> Can you tell me why the data in my tranaction log files has not committed
> to the db files? You said "Shortly", but the last entry was 1/18/2007 in
> the db file. Things are added to this db everyday by my user. Why are
> they all staying in the transaction log file and not being committed. Can
> I force it to commit some how? There are 1027 records in the log files and
> I want to commit them to the db file. Will changing db to SIMPLE force it
> to commit the data? I'm not going to lose what I have in the Log files am
> I?
Umm, how are you determining that things are NOT being committed?
If you do a select against inserted data, if you're seeing it, (and not
using read uncommitted) the data is definitely committed.
If you're basing your assumptions on FILE dates, then two things:
1) The file date on the file is the last time the file was OPENED or the
SIZE of it was changed.
So it sounds like you're looking at the file size of the MDF and assuming
nothing is committed since the data hasn't changed. This isn't really true.
2) If the size of the transaction log is GROWING, this means you're not
doing transaction log backups most likely. Which means your recovery plans
probably wont' be good.

>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com

Is Truncating Log commiting data the the actual DB?

Newbie question running SQL 2k
My last entry in the .mdb file was January and everything else has been
sitting in the Transaction log files. Everything works fine. I'm just
wondering if Truncating the logs mean I'm going to commit the data from the
log files to the .mdb file. So if I truncate and look in the .mdb file,
will I see all my entries up to the most current period?
Thanks!AFAIK you will not see the data in the datafile until it is commited. And SQL
Server will not truncate stuff that is not commited or saved (for example
with a log backup).
Truncating the log means, that you truncate the unused or unneccessary data
from the logfile that is not neccessary any more.
regards
Andreas
"Phillip Vong" wrote:
> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from the
> log files to the .mdb file. So if I truncate and look in the .mdb file,
> will I see all my entries up to the most current period?
> Thanks!
>
>|||Phillip,
The data in the transaction log files is committed to the database files not
long after the transaction is written to the log. There are a number of
factors to consider, but if nobody has changed anything since January it all
should be in the database by now.
Truncating the log is throwing away the transaction records that could be
used to recover in case of a failure. Actually, you almost never should
truncate. If you do not want the logs, change to the SIMPLE recovery model.
And make sure that you backup the database regularly.
The behavior of transaction logs is discussed under the backup and restore
strategy portions of the Books Online, so you need to familiarize yourself
with those. It is not too complicated.
RLF
"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
> Newbie question running SQL 2k
> My last entry in the .mdb file was January and everything else has been
> sitting in the Transaction log files. Everything works fine. I'm just
> wondering if Truncating the logs mean I'm going to commit the data from
> the log files to the .mdb file. So if I truncate and look in the .mdb
> file, will I see all my entries up to the most current period?
> Thanks!
>|||Russell, thanks for the update.
Can you tell me why the data in my tranaction log files has not committed to
the db files? You said "Shortly", but the last entry was 1/18/2007 in the
db file. Things are added to this db everyday by my user. Why are they all
staying in the transaction log file and not being committed. Can I force it
to commit some how? There are 1027 records in the log files and I want to
commit them to the db file. Will changing db to SIMPLE force it to commit
the data? I'm not going to lose what I have in the Log files am I?
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:%23Gnin2lYHHA.992@.TK2MSFTNGP02.phx.gbl...
> Phillip,
> The data in the transaction log files is committed to the database files
> not long after the transaction is written to the log. There are a number
> of factors to consider, but if nobody has changed anything since January
> it all should be in the database by now.
> Truncating the log is throwing away the transaction records that could be
> used to recover in case of a failure. Actually, you almost never should
> truncate. If you do not want the logs, change to the SIMPLE recovery
> model. And make sure that you backup the database regularly.
> The behavior of transaction logs is discussed under the backup and restore
> strategy portions of the Books Online, so you need to familiarize yourself
> with those. It is not too complicated.
> RLF
> "Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
> news:eSU5ZElYHHA.3256@.TK2MSFTNGP04.phx.gbl...
>> Newbie question running SQL 2k
>> My last entry in the .mdb file was January and everything else has been
>> sitting in the Transaction log files. Everything works fine. I'm just
>> wondering if Truncating the logs mean I'm going to commit the data from
>> the log files to the .mdb file. So if I truncate and look in the .mdb
>> file, will I see all my entries up to the most current period?
>> Thanks!
>>
>|||"Phillip Vong" <phillip_vong*at*yahoo*dot*com> wrote in message
news:uWxxX%23mYHHA.3984@.TK2MSFTNGP02.phx.gbl...
> Russell, thanks for the update.
> Can you tell me why the data in my tranaction log files has not committed
> to the db files? You said "Shortly", but the last entry was 1/18/2007 in
> the db file. Things are added to this db everyday by my user. Why are
> they all staying in the transaction log file and not being committed. Can
> I force it to commit some how? There are 1027 records in the log files and
> I want to commit them to the db file. Will changing db to SIMPLE force it
> to commit the data? I'm not going to lose what I have in the Log files am
> I?
Umm, how are you determining that things are NOT being committed?
If you do a select against inserted data, if you're seeing it, (and not
using read uncommitted) the data is definitely committed.
If you're basing your assumptions on FILE dates, then two things:
1) The file date on the file is the last time the file was OPENED or the
SIZE of it was changed.
So it sounds like you're looking at the file size of the MDF and assuming
nothing is committed since the data hasn't changed. This isn't really true.
2) If the size of the transaction log is GROWING, this means you're not
doing transaction log backups most likely. Which means your recovery plans
probably wont' be good.
>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com

Is transaction log file reuseable after data file is Restored?

We have a database that is set to Simple recovery mode and is backed up
every night. The data files and sql server and OS files are on the same
disk and the log file is on a different disk. (There are no log file
backups.)
During the day the disk controller on the disk with the data files has
failed and has subsequently been replaced and is being restored from tape.
My question is: can the log file on the other (healty) disk be reliably used
to "replay" it's committed transactions into the restored database?
thanks,
Paul Ritchie.
No. When you restore the FULL Database backup, it will write over the
existing log file. Whatever transactions that were in the transaction log
when the backup was taken and committed will roll forward, all those that
had not committed will roll back. This is called recovery. You will end up
with a database in a state it was in when the backup was taken.
Sincerely,
Anthony Thomas

"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
We have a database that is set to Simple recovery mode and is backed up
every night. The data files and sql server and OS files are on the same
disk and the log file is on a different disk. (There are no log file
backups.)
During the day the disk controller on the disk with the data files has
failed and has subsequently been replaced and is being restored from tape.
My question is: can the log file on the other (healty) disk be reliably used
to "replay" it's committed transactions into the restored database?
thanks,
Paul Ritchie.
|||Thanks Anthony,
So we're saying that committed transactions in the log file of a database
set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
Explorer I guess!)
ie these are transactions that have occurred subsequent to the backup being
taken. The MDF file is lost and restored from backup and this perfectly
good record of the subsequent transactions is not able to be used?
Why keep them then?
cheers,
Paul.
"AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
> No. When you restore the FULL Database backup, it will write over the
> existing log file. Whatever transactions that were in the transaction log
> when the backup was taken and committed will roll forward, all those that
> had not committed will roll back. This is called recovery. You will end
up
> with a database in a state it was in when the backup was taken.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
> news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
> We have a database that is set to Simple recovery mode and is backed up
> every night. The data files and sql server and OS files are on the same
> disk and the log file is on a different disk. (There are no log file
> backups.)
> During the day the disk controller on the disk with the data files has
> failed and has subsequently been replaced and is being restored from tape.
> My question is: can the log file on the other (healty) disk be reliably
used
> to "replay" it's committed transactions into the restored database?
> thanks,
> Paul Ritchie.
>
|||"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uYhlBvu4EHA.2196@.TK2MSFTNGP14.phx.gbl...
> Thanks Anthony,
> So we're saying that committed transactions in the log file of a database
> set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
> Explorer I guess!)
>
Not even them. Committed transactions are deleted from the log file upon a
checkpoint in SIMPLE RECOVERY mode.
So, within minutes (or less) the log file no logner has that transaction
anymore.

> ie these are transactions that have occurred subsequent to the backup
being
> taken. The MDF file is lost and restored from backup and this perfectly
> good record of the subsequent transactions is not able to be used?
> Why keep them then?
In Simple mode they aren't kept.
In FULL they are and can be used.
[vbcol=seagreen]
> cheers,
> Paul.
> "AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
> news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
log[vbcol=seagreen]
that[vbcol=seagreen]
end[vbcol=seagreen]
> up
tape.
> used
>
|||It is not for the COMMITTED transactions that the log files are used for.
Regardless of RECOVERY mode, it is the in process, non-committed, open
transactions that the log files are used for, without them, then there would
be no ROLLBACK during the reocvery process. This is the part of the ACID
properties that keeps the database consistent: if I pull money from one
account, it BETTER show up in another, viz., completely committed.
Sincerely,
Anthony Thomas

"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:PT7wd.1397$DQ3.1285@.twister.nyroc.rr.com...
"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uYhlBvu4EHA.2196@.TK2MSFTNGP14.phx.gbl...
> Thanks Anthony,
> So we're saying that committed transactions in the log file of a database
> set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
> Explorer I guess!)
>
Not even them. Committed transactions are deleted from the log file upon a
checkpoint in SIMPLE RECOVERY mode.
So, within minutes (or less) the log file no logner has that transaction
anymore.

> ie these are transactions that have occurred subsequent to the backup
being
> taken. The MDF file is lost and restored from backup and this perfectly
> good record of the subsequent transactions is not able to be used?
> Why keep them then?
In Simple mode they aren't kept.
In FULL they are and can be used.
[vbcol=seagreen]
> cheers,
> Paul.
> "AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
> news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
log[vbcol=seagreen]
that[vbcol=seagreen]
end[vbcol=seagreen]
> up
tape.
> used
>

Is transaction log file reuseable after data file is Restored?

We have a database that is set to Simple recovery mode and is backed up
every night. The data files and sql server and OS files are on the same
disk and the log file is on a different disk. (There are no log file
backups.)
During the day the disk controller on the disk with the data files has
failed and has subsequently been replaced and is being restored from tape.
My question is: can the log file on the other (healty) disk be reliably used
to "replay" it's committed transactions into the restored database?
thanks,
Paul Ritchie.No. When you restore the FULL Database backup, it will write over the
existing log file. Whatever transactions that were in the transaction log
when the backup was taken and committed will roll forward, all those that
had not committed will roll back. This is called recovery. You will end up
with a database in a state it was in when the backup was taken.
Sincerely,
Anthony Thomas
"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
We have a database that is set to Simple recovery mode and is backed up
every night. The data files and sql server and OS files are on the same
disk and the log file is on a different disk. (There are no log file
backups.)
During the day the disk controller on the disk with the data files has
failed and has subsequently been replaced and is being restored from tape.
My question is: can the log file on the other (healty) disk be reliably used
to "replay" it's committed transactions into the restored database?
thanks,
Paul Ritchie.|||Thanks Anthony,
So we're saying that committed transactions in the log file of a database
set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
Explorer I guess!)
ie these are transactions that have occurred subsequent to the backup being
taken. The MDF file is lost and restored from backup and this perfectly
good record of the subsequent transactions is not able to be used?
Why keep them then?
cheers,
Paul.
"AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
> No. When you restore the FULL Database backup, it will write over the
> existing log file. Whatever transactions that were in the transaction log
> when the backup was taken and committed will roll forward, all those that
> had not committed will roll back. This is called recovery. You will end
up
> with a database in a state it was in when the backup was taken.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
> news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
> We have a database that is set to Simple recovery mode and is backed up
> every night. The data files and sql server and OS files are on the same
> disk and the log file is on a different disk. (There are no log file
> backups.)
> During the day the disk controller on the disk with the data files has
> failed and has subsequently been replaced and is being restored from tape.
> My question is: can the log file on the other (healty) disk be reliably
used
> to "replay" it's committed transactions into the restored database?
> thanks,
> Paul Ritchie.
>|||"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uYhlBvu4EHA.2196@.TK2MSFTNGP14.phx.gbl...
> Thanks Anthony,
> So we're saying that committed transactions in the log file of a database
> set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
> Explorer I guess!)
>
Not even them. Committed transactions are deleted from the log file upon a
checkpoint in SIMPLE RECOVERY mode.
So, within minutes (or less) the log file no logner has that transaction
anymore.
> ie these are transactions that have occurred subsequent to the backup
being
> taken. The MDF file is lost and restored from backup and this perfectly
> good record of the subsequent transactions is not able to be used?
> Why keep them then?
In Simple mode they aren't kept.
In FULL they are and can be used.
> cheers,
> Paul.
> "AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
> news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
> > No. When you restore the FULL Database backup, it will write over the
> > existing log file. Whatever transactions that were in the transaction
log
> > when the backup was taken and committed will roll forward, all those
that
> > had not committed will roll back. This is called recovery. You will
end
> up
> > with a database in a state it was in when the backup was taken.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > --
> >
> > "Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
> > news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
> > We have a database that is set to Simple recovery mode and is backed up
> > every night. The data files and sql server and OS files are on the same
> > disk and the log file is on a different disk. (There are no log file
> > backups.)
> >
> > During the day the disk controller on the disk with the data files has
> > failed and has subsequently been replaced and is being restored from
tape.
> >
> > My question is: can the log file on the other (healty) disk be reliably
> used
> > to "replay" it's committed transactions into the restored database?
> >
> > thanks,
> > Paul Ritchie.
> >
> >
>|||It is not for the COMMITTED transactions that the log files are used for.
Regardless of RECOVERY mode, it is the in process, non-committed, open
transactions that the log files are used for, without them, then there would
be no ROLLBACK during the reocvery process. This is the part of the ACID
properties that keeps the database consistent: if I pull money from one
account, it BETTER show up in another, viz., completely committed.
Sincerely,
Anthony Thomas
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:PT7wd.1397$DQ3.1285@.twister.nyroc.rr.com...
"Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
news:uYhlBvu4EHA.2196@.TK2MSFTNGP14.phx.gbl...
> Thanks Anthony,
> So we're saying that committed transactions in the log file of a database
> set to 'Simple' recovery are of no use to anyone? (Except Lumigent Log
> Explorer I guess!)
>
Not even them. Committed transactions are deleted from the log file upon a
checkpoint in SIMPLE RECOVERY mode.
So, within minutes (or less) the log file no logner has that transaction
anymore.
> ie these are transactions that have occurred subsequent to the backup
being
> taken. The MDF file is lost and restored from backup and this perfectly
> good record of the subsequent transactions is not able to be used?
> Why keep them then?
In Simple mode they aren't kept.
In FULL they are and can be used.
> cheers,
> Paul.
> "AnthonyThomas" <Anthony.Thomas@.CommerceBank.com> wrote in message
> news:%23FLU0ha4EHA.936@.TK2MSFTNGP12.phx.gbl...
> > No. When you restore the FULL Database backup, it will write over the
> > existing log file. Whatever transactions that were in the transaction
log
> > when the backup was taken and committed will roll forward, all those
that
> > had not committed will roll back. This is called recovery. You will
end
> up
> > with a database in a state it was in when the backup was taken.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > --
> >
> > "Paul Ritchie" <pritREMOVEchie@.xtREMOVEra.co.nzREMOVE> wrote in message
> > news:uqpOBmY4EHA.3368@.TK2MSFTNGP10.phx.gbl...
> > We have a database that is set to Simple recovery mode and is backed up
> > every night. The data files and sql server and OS files are on the same
> > disk and the log file is on a different disk. (There are no log file
> > backups.)
> >
> > During the day the disk controller on the disk with the data files has
> > failed and has subsequently been replaced and is being restored from
tape.
> >
> > My question is: can the log file on the other (healty) disk be reliably
> used
> > to "replay" it's committed transactions into the restored database?
> >
> > thanks,
> > Paul Ritchie.
> >
> >
>sql

is this the best way to backup more than one database

I am setting up a DTS so that we can backup each of the database, is this the best way to back up each of the mdf & ldf files to another server? cheers

EXEC sp_addumpdevice 'disk', 'cc_150_chg', '\\homer\db_backups$\cc_150_chg.mdf'
EXEC sp_addumpdevice 'disk', 'cc_150_chg_admin', '\\homer\db_backups$\cc_150_chg_admin.mdf'
EXEC sp_addumpdevice 'disk', 'cc_150_chg_Log', '\\homer\db_backups$\cc_150_chg_log.ldf'
EXEC sp_addumpdevice 'disk', 'cc_150_chg_admin_log', '\\homer\db_backups$\cc_150_chg_admin.ldf'
EXEC sp_addumpdevice 'disk', 'cc_153', '\\homer\db_backups$\cc_153.mdf'
EXEC sp_addumpdevice 'disk', 'cc_153_log', '\\homer\db_backups$\cc_153.ldf'
EXEC sp_addumpdevice 'disk', 'cc_153_admin', '\\homer\db_backups$\cc_153_admin.mdf'
EXEC

This will form part of the step in 'command line'?

Cheers
EWhy don't you just backup to a file?|||backup all the database to a file? How can I do this? also do i need to specifiy all the databases individually by backuping both mdf & ldf files?|||Backup each database to a separate file. You don't need to back up the log files (ldf) unless you need point-in-time restore.|||You don't need to back up the log files (ldf)

You're fired|||alll sorted!!!!1thanx|||OK Brett, YOU explain the whole concept of log files to him! I got actual work I gotta do today.

...or just point him to Books Online...

:)|||OK Brett, YOU explain the whole concept of log files to him! I got actual work I gotta do today.

...or just point him to Books Online...

:)

Settle down...

Hey, there's a first time for everything, too

OR, I could just post Tara's blog

http://weblogs.sqlteam.com/tarad/category/95.aspx

I think I've stolen most of that...

Let me ask...when was the last time, aside from testing contingency, that you had to do a restore, and have to reapply all of the logs?

I don't remeber...had to be 6.5

Is this possible with SSRS?

Hi. We currently have about a 100 Crystal Reports with embedded images and text in the *.rpt files. If we were to switch to SSRS 2005,
Can we do a global search-and-replace of images and text within the SSRS reports? We have some letterheads that have names of people who might change every year or two.
Are there any tools to convert Crystal Reports *.rpt files to SSRS reports? These 100 reports would be time-consuming trying to convert to SSRS.
Thank you much
Alex

1. Yes.

2.

I’ve been asked many times if Microsoft provide a tool for converting legacy Crystal Reports to SQL Server Reporting Services. The answer is no. However I do know someone who does.

Hitachi Consulting has an RDL generator that will generate RDL from Crystal Report formats. They’re in the States but I’m sure they’ll be able to help UK customers.

You can find a link to their site from this list of all our Reporting Services consulting partners: http://www.microsoft.com/sql/reporting/partners/consulting.asp[/quote]

http://blogs.technet.com/mat_stephen/archive/2005/02/01/convert-crystal-reports-to-sql-server-reporting-services.aspx

|||

1. Unlike Crystal, SSRS has an open XML-based report definition language. So, you can either use a file utility to search and replace or programaitcally load the report definition, e.g. in XMLDOM, with more involved requirements.

2. To my understanding, Business Objects doesn't currently let third-party vendors to offer migration tools. Instead, most companies do this as a service where you pay the company to convert the reports for you. This is actually a good possibility for outsourcing. Greg provided links to some vendors.

Is there any way to tell when a database file grew

We have all the files in our database set to autogrow by 10%. During the
day we encountered a 5 minute time period in which SQL activity seemed to
come to a halt. I suspect that during that time period, one of the database
files grew.
Is there any way that I could tell this by looking at a catalog table?
Thanks in advance.
Only if you had a trace running at that time with the autogrow event
selected. It is rare that 10% is appropriate for autogrowth setting. On a
larger file size this can take a long time to grow. It should be set to a
fixed amount that will grow in 15 seconds or less. That way you avoid most
timeouts and issues like you have. But it is always best to keep a lot of
free space in the files at all times to avoid autogrow altogether. Make
sure you don't have auto shrink on or a job to shrink them.
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
> We have all the files in our database set to autogrow by 10%. During the
> day we encountered a 5 minute time period in which SQL activity seemed to
> come to a halt. I suspect that during that time period, one of the
> database
> files grew.
> Is there any way that I could tell this by looking at a catalog table?
> Thanks in advance.
>
|||Thanks for the reply Andrew. The file is currently 70GB so therefore the
growthsize is approximately 7GB.
Would an autogrow extent of that size cause a "standstill" for about 5
minutes?
Thanks,
Tom
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:O6ZWb2n3FHA.1416@.TK2MSFTNGP09.phx.gbl...
> Only if you had a trace running at that time with the autogrow event
> selected. It is rare that 10% is appropriate for autogrowth setting. On
a[vbcol=seagreen]
> larger file size this can take a long time to grow. It should be set to a
> fixed amount that will grow in 15 seconds or less. That way you avoid most
> timeouts and issues like you have. But it is always best to keep a lot of
> free space in the files at all times to avoid autogrow altogether. Make
> sure you don't have auto shrink on or a job to shrink them.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
the[vbcol=seagreen]
to
>
|||"TJT" <TJT@.nospam.com> wrote in message
news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
> Thanks for the reply Andrew. The file is currently 70GB so therefore the
> growthsize is approximately 7GB.
> Would an autogrow extent of that size cause a "standstill" for about 5
> minutes?
>
Quite possible, depending on the other IO activity at the time.
David
|||Would I experience the same problem if I tried to expand the file while
there is free space in the file? In other words - does this problem only
occur when there is 0 free space available?
Thanks,
Tom
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> "TJT" <TJT@.nospam.com> wrote in message
> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
the
> Quite possible, depending on the other IO activity at the time.
> David
>
|||"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
>
The amount of free space doesn't really matter. What matters is what else
is going on when the file expands. Ideally you could expand the files at an
off-peak time when users wouldn't be affected and no other workloads are
contending for the volume on which the data file resides.
David
|||You can get two issues from an auto grow. The first and most prevalent is
that when Autogrow kickis in that means there is no more space in the file
for the current transaction. That transaction waits until the growth is
completed before it continues. The transaction can actually timeout before
the growth is complete and cause the growth to roll back. Now you are back
to square one again. The other issue may be that if you have very poor I/O
you can affect others that require I/O as well.
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> the
>
|||Thanks so much guys - I really appreciate the help!
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:Ojo7XIp3FHA.3400@.tk2msftngp13.phx.gbl...
> You can get two issues from an auto grow. The first and most prevalent is
> that when Autogrow kickis in that means there is no more space in the file
> for the current transaction. That transaction waits until the growth is
> completed before it continues. The transaction can actually timeout before
> the growth is complete and cause the growth to roll back. Now you are back
> to square one again. The other issue may be that if you have very poor
I/O[vbcol=seagreen]
> you can affect others that require I/O as well.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
only[vbcol=seagreen]
5
>
|||Growing in advance is much better. Grow doesn't block operations for which space is available
(operations that uses current space (on same page, extent etc)) or space free in the db file (as it
is when you grow in advance). Grow does block operations that requires new space which isn't
available (which is the case when all extents are used and you do, say, an insert on a table for
which all current extents are used and all pages on those extents are full, and also other similar
operations that are initiated while the grow operation is running.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"TJT" <TJT@.nospam.com> wrote in message news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> the
>

Is there any way to tell when a database file grew

We have all the files in our database set to autogrow by 10%. During the
day we encountered a 5 minute time period in which SQL activity seemed to
come to a halt. I suspect that during that time period, one of the database
files grew.
Is there any way that I could tell this by looking at a catalog table?
Thanks in advance.Only if you had a trace running at that time with the autogrow event
selected. It is rare that 10% is appropriate for autogrowth setting. On a
larger file size this can take a long time to grow. It should be set to a
fixed amount that will grow in 15 seconds or less. That way you avoid most
timeouts and issues like you have. But it is always best to keep a lot of
free space in the files at all times to avoid autogrow altogether. Make
sure you don't have auto shrink on or a job to shrink them.
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
> We have all the files in our database set to autogrow by 10%. During the
> day we encountered a 5 minute time period in which SQL activity seemed to
> come to a halt. I suspect that during that time period, one of the
> database
> files grew.
> Is there any way that I could tell this by looking at a catalog table?
> Thanks in advance.
>|||Thanks for the reply Andrew. The file is currently 70GB so therefore the
growthsize is approximately 7GB.
Would an autogrow extent of that size cause a "standstill" for about 5
minutes?
Thanks,
Tom
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:O6ZWb2n3FHA.1416@.TK2MSFTNGP09.phx.gbl...
> Only if you had a trace running at that time with the autogrow event
> selected. It is rare that 10% is appropriate for autogrowth setting. On
a
> larger file size this can take a long time to grow. It should be set to a
> fixed amount that will grow in 15 seconds or less. That way you avoid most
> timeouts and issues like you have. But it is always best to keep a lot of
> free space in the files at all times to avoid autogrow altogether. Make
> sure you don't have auto shrink on or a job to shrink them.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
the[vbcol=seagreen]
to[vbcol=seagreen]
>|||"TJT" <TJT@.nospam.com> wrote in message
news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
> Thanks for the reply Andrew. The file is currently 70GB so therefore the
> growthsize is approximately 7GB.
> Would an autogrow extent of that size cause a "standstill" for about 5
> minutes?
>
Quite possible, depending on the other IO activity at the time.
David|||Would I experience the same problem if I tried to expand the file while
there is free space in the file? In other words - does this problem only
occur when there is 0 free space available?
Thanks,
Tom
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> "TJT" <TJT@.nospam.com> wrote in message
> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
the[vbcol=seagreen]
> Quite possible, depending on the other IO activity at the time.
> David
>|||"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
>
The amount of free space doesn't really matter. What matters is what else
is going on when the file expands. Ideally you could expand the files at an
off-peak time when users wouldn't be affected and no other workloads are
contending for the volume on which the data file resides.
David|||You can get two issues from an auto grow. The first and most prevalent is
that when Autogrow kickis in that means there is no more space in the file
for the current transaction. That transaction waits until the growth is
completed before it continues. The transaction can actually timeout before
the growth is complete and cause the growth to roll back. Now you are back
to square one again. The other issue may be that if you have very poor I/O
you can affect others that require I/O as well.
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> the
>|||Thanks so much guys - I really appreciate the help!
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:Ojo7XIp3FHA.3400@.tk2msftngp13.phx.gbl...
> You can get two issues from an auto grow. The first and most prevalent is
> that when Autogrow kickis in that means there is no more space in the file
> for the current transaction. That transaction waits until the growth is
> completed before it continues. The transaction can actually timeout before
> the growth is complete and cause the growth to roll back. Now you are back
> to square one again. The other issue may be that if you have very poor
I/O
> you can affect others that require I/O as well.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
only[vbcol=seagreen]
5[vbcol=seagreen]
>|||Growing in advance is much better. Grow doesn't block operations for which s
pace is available
(operations that uses current space (on same page, extent etc)) or space fre
e in the db file (as it
is when you grow in advance). Grow does block operations that requires new s
pace which isn't
available (which is the case when all extents are used and you do, say, an i
nsert on a table for
which all current extents are used and all pages on those extents are full,
and also other similar
operations that are initiated while the grow operation is running.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"TJT" <TJT@.nospam.com> wrote in message news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...[vbco
l=seagreen]
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> the
>[/vbcol]

Is there any way to tell when a database file grew

We have all the files in our database set to autogrow by 10%. During the
day we encountered a 5 minute time period in which SQL activity seemed to
come to a halt. I suspect that during that time period, one of the database
files grew.
Is there any way that I could tell this by looking at a catalog table?
Thanks in advance.Only if you had a trace running at that time with the autogrow event
selected. It is rare that 10% is appropriate for autogrowth setting. On a
larger file size this can take a long time to grow. It should be set to a
fixed amount that will grow in 15 seconds or less. That way you avoid most
timeouts and issues like you have. But it is always best to keep a lot of
free space in the files at all times to avoid autogrow altogether. Make
sure you don't have auto shrink on or a job to shrink them.
--
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
> We have all the files in our database set to autogrow by 10%. During the
> day we encountered a 5 minute time period in which SQL activity seemed to
> come to a halt. I suspect that during that time period, one of the
> database
> files grew.
> Is there any way that I could tell this by looking at a catalog table?
> Thanks in advance.
>|||Thanks for the reply Andrew. The file is currently 70GB so therefore the
growthsize is approximately 7GB.
Would an autogrow extent of that size cause a "standstill" for about 5
minutes?
Thanks,
Tom
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:O6ZWb2n3FHA.1416@.TK2MSFTNGP09.phx.gbl...
> Only if you had a trace running at that time with the autogrow event
> selected. It is rare that 10% is appropriate for autogrowth setting. On
a
> larger file size this can take a long time to grow. It should be set to a
> fixed amount that will grow in 15 seconds or less. That way you avoid most
> timeouts and issues like you have. But it is always best to keep a lot of
> free space in the files at all times to avoid autogrow altogether. Make
> sure you don't have auto shrink on or a job to shrink them.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:OnKI7sn3FHA.3400@.tk2msftngp13.phx.gbl...
> > We have all the files in our database set to autogrow by 10%. During
the
> > day we encountered a 5 minute time period in which SQL activity seemed
to
> > come to a halt. I suspect that during that time period, one of the
> > database
> > files grew.
> >
> > Is there any way that I could tell this by looking at a catalog table?
> >
> > Thanks in advance.
> >
> >
>|||"TJT" <TJT@.nospam.com> wrote in message
news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
> Thanks for the reply Andrew. The file is currently 70GB so therefore the
> growthsize is approximately 7GB.
> Would an autogrow extent of that size cause a "standstill" for about 5
> minutes?
>
Quite possible, depending on the other IO activity at the time.
David|||Would I experience the same problem if I tried to expand the file while
there is free space in the file? In other words - does this problem only
occur when there is 0 free space available?
Thanks,
Tom
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> "TJT" <TJT@.nospam.com> wrote in message
> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
> > Thanks for the reply Andrew. The file is currently 70GB so therefore
the
> > growthsize is approximately 7GB.
> >
> > Would an autogrow extent of that size cause a "standstill" for about 5
> > minutes?
> >
> Quite possible, depending on the other IO activity at the time.
> David
>|||"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
>
The amount of free space doesn't really matter. What matters is what else
is going on when the file expands. Ideally you could expand the files at an
off-peak time when users wouldn't be affected and no other workloads are
contending for the volume on which the data file resides.
David|||You can get two issues from an auto grow. The first and most prevalent is
that when Autogrow kickis in that means there is no more space in the file
for the current transaction. That transaction waits until the growth is
completed before it continues. The transaction can actually timeout before
the growth is complete and cause the growth to roll back. Now you are back
to square one again. The other issue may be that if you have very poor I/O
you can affect others that require I/O as well.
--
Andrew J. Kelly SQL MVP
"TJT" <TJT@.nospam.com> wrote in message
news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
>> "TJT" <TJT@.nospam.com> wrote in message
>> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
>> > Thanks for the reply Andrew. The file is currently 70GB so therefore
> the
>> > growthsize is approximately 7GB.
>> >
>> > Would an autogrow extent of that size cause a "standstill" for about 5
>> > minutes?
>> >
>> Quite possible, depending on the other IO activity at the time.
>> David
>>
>|||Thanks so much guys - I really appreciate the help!
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:Ojo7XIp3FHA.3400@.tk2msftngp13.phx.gbl...
> You can get two issues from an auto grow. The first and most prevalent is
> that when Autogrow kickis in that means there is no more space in the file
> for the current transaction. That transaction waits until the growth is
> completed before it continues. The transaction can actually timeout before
> the growth is complete and cause the growth to roll back. Now you are back
> to square one again. The other issue may be that if you have very poor
I/O
> you can affect others that require I/O as well.
> --
> Andrew J. Kelly SQL MVP
>
> "TJT" <TJT@.nospam.com> wrote in message
> news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> > Would I experience the same problem if I tried to expand the file while
> > there is free space in the file? In other words - does this problem
only
> > occur when there is 0 free space available?
> >
> > Thanks,
> > Tom
> >
> >
> > "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> > message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
> >>
> >> "TJT" <TJT@.nospam.com> wrote in message
> >> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
> >> > Thanks for the reply Andrew. The file is currently 70GB so therefore
> > the
> >> > growthsize is approximately 7GB.
> >> >
> >> > Would an autogrow extent of that size cause a "standstill" for about
5
> >> > minutes?
> >> >
> >>
> >> Quite possible, depending on the other IO activity at the time.
> >>
> >> David
> >>
> >>
> >
> >
>|||Growing in advance is much better. Grow doesn't block operations for which space is available
(operations that uses current space (on same page, extent etc)) or space free in the db file (as it
is when you grow in advance). Grow does block operations that requires new space which isn't
available (which is the case when all extents are used and you do, say, an insert on a table for
which all current extents are used and all pages on those extents are full, and also other similar
operations that are initiated while the grow operation is running.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"TJT" <TJT@.nospam.com> wrote in message news:%239U$1Uo3FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Would I experience the same problem if I tried to expand the file while
> there is free space in the file? In other words - does this problem only
> occur when there is 0 free space available?
> Thanks,
> Tom
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:%23OlYpLo3FHA.3296@.TK2MSFTNGP09.phx.gbl...
>> "TJT" <TJT@.nospam.com> wrote in message
>> news:e1KTM$n3FHA.268@.TK2MSFTNGP10.phx.gbl...
>> > Thanks for the reply Andrew. The file is currently 70GB so therefore
> the
>> > growthsize is approximately 7GB.
>> >
>> > Would an autogrow extent of that size cause a "standstill" for about 5
>> > minutes?
>> >
>> Quite possible, depending on the other IO activity at the time.
>> David
>>
>

Is there any way to read the transaction log?

Hi there,

I need to recover certain transactions that I made on the server.

Those transactions were in scripts and I lost the files.

Is there a way to read the transaction log so that I can see what transactions were executed?

TIA

I would have a look at the product LogExplorer as it should do what you need.

|||The transaction log is a binary structure and is not designed to give this sort of information. As Glen points out, there are third-party companies who have licensed the file layouts from us and are able to reproduce the original statements from the logs. Lumigent's Log Explorer is one of these.

Is there any way to read the transaction log?

Hi there,

I need to recover certain transactions that I made on the server.

Those transactions were in scripts and I lost the files.

Is there a way to read the transaction log so that I can see what transactions were executed?

TIA

I would have a look at the product LogExplorer as it should do what you need.

|||The transaction log is a binary structure and is not designed to give this sort of information. As Glen points out, there are third-party companies who have licensed the file layouts from us and are able to reproduce the original statements from the logs. Lumigent's Log Explorer is one of these.

is there any way of uploading/deploying rdl files to the reportserver other than report manager

Hi,

is there any way of uploading/deploying rdl files to the reportserver other than report manager in real time

wat happened:-

i had developed reports (rdl files) and we have a setup for the web application

During Implementation

after the application is installed in the web server. we needed to deploy reports & datasources (rdl & rds files) to the report server.

wat we did was - manually upload each rdl file using report manager. and the eventually the datasource which the reports use was uploaded.

but problem here was when i ran the report it did not find/recognize the datasource it wanted although i had uploaded it. and i had to manually set the datasource once again for all the reports. assume there are 50 reports do i need to do it everytime for each report manually?

is there any way all these can be done programmatically ?

Sure it can be done programmatically by SOAP API.

CreateDataSource () to create a data source

CreateReport () to create a report

SetReportDataSources() to bind a report to a data source

|||

thanks for the reply

I am new to .NET technology.

how do i refer or implement SOAP API in my application

by the way ...

CreateReport () to create a report

SetReportDataSources() to bind a report to a data source

.... these above methods are used to create a new report or deploy already designed report to the report server

|||

basically i need a sample which allows me to pick & upload a rdl and rds file to report server.

pls help me out to give me either links or samples

|||

In Visual Studio, add a web reference to the SOAP endpoint for RS. The url is http://<servername>/ReportService/ReportService2005.asmx.

Once you have done that, your project in VS should be able to use the RS SOAP APIs. In your case, what you will have to do is open the .RDL file, and pass the contents of that file to CreateReport().

This sample on MSDN should give you enough information:

http://msdn2.microsoft.com/en-us/library/ms169926.aspx

Is there any way better than XP_CMDSHELL?

Hi ..
I want to Write in files or read from files
for example i have My_File.txt . i need a syntax and i want to call this syntax in my Store procedure and this syntax write forexample " Hello Word " in My_File.txt .
and i want another syntax that read from My_File.txt forexample "Word" from My_File.txt . what are those syntaxes do that ??

Is there any way better than XP_CMDSHELL for writing in or reading from MyFile.txt ??

thanksYou could BCP the SQL file into a temporary table and then execute the code through dynamic SQL, but that is pretty round-a-bout.

Is there any free tools taht I could read t sql 2005 log files

Hi,
I need to read sql2005 log files. Red gate has sql2000 one for free. I need
sql2005.
any ideas?
thanks
I don't of any free tools. As a matter of fact, they are pretty pricey since
people are usually in a bind when they go looking for them. However, I
believe they are just a gui on dbcc log so you could look into that command.
It is pretty cryptic though.
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
"Mecn" <mecn@.yahoo.com> wrote in message
news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
> Hi,
> I need to read sql2005 log files. Red gate has sql2000 one for free. I
> need sql2005.
> any ideas?
> thanks
>
|||I tried. It desn't really tell me anything.
What I need is that It shows the sql stetement (update, select and delete
ect.. and user name....)
Thanks
"Jason Massie" <jason**R3move**@.statisticsio.com> wrote in message
news:eAPgbG0mIHA.944@.TK2MSFTNGP05.phx.gbl...
>I don't of any free tools. As a matter of fact, they are pretty pricey
>since people are usually in a bind when they go looking for them. However,
>I believe they are just a gui on dbcc log so you could look into that
>command. It is pretty cryptic though.
> --
> Jason Massie
> Web: http://statisticsio.com
> RSS: http://feeds.feedburner.com/statisticsio
> "Mecn" <mecn@.yahoo.com> wrote in message
> news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
>
|||On Thu, 10 Apr 2008 15:59:48 -0400, Mecn wrote:

> I tried. It desn't really tell me anything.
> What I need is that It shows the sql stetement (update, select and delete
> ect.. and user name....)
> Thanks
The log does not store sql statements. It only stores information regarding
changes that were made to pages in the database (i.e. were rows
inserted/updated/deleted).
Thanks,
Marcel van der Holst
SQL Server Storage Engine Team.
[vbcol=seagreen]
>
> "Jason Massie" <jason**R3move**@.statisticsio.com> wrote in message
> news:eAPgbG0mIHA.944@.TK2MSFTNGP05.phx.gbl...
|||Pay the money (surprisingly little, actually) for apexsql.com's Log product.
Every production environment should have a tool such as this available for
the 'holy-shit' times. Also helps trememdously during
debugging/troubleshooting scenarios too.
Disclaimer: I work closely with Apex, I use and promote their products to
my clients. If you tell them TheSQLGuru sent you you can pick up a nice
discount (and I will receive a small referral fee). They have a wide array
of very useful SQL Server-specific tools.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Mecn" <mecn@.yahoo.com> wrote in message
news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
> Hi,
> I need to read sql2005 log files. Red gate has sql2000 one for free. I
> need sql2005.
> any ideas?
> thanks
>

Is there any free tools taht I could read t sql 2005 log files

Hi,
I need to read sql2005 log files. Red gate has sql2000 one for free. I need
sql2005.
any ideas?
thanksI don't of any free tools. As a matter of fact, they are pretty pricey since
people are usually in a bind when they go looking for them. However, I
believe they are just a gui on dbcc log so you could look into that command.
It is pretty cryptic though.
--
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
"Mecn" <mecn@.yahoo.com> wrote in message
news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
> Hi,
> I need to read sql2005 log files. Red gate has sql2000 one for free. I
> need sql2005.
> any ideas?
> thanks
>|||I tried. It desn't really tell me anything.
What I need is that It shows the sql stetement (update, select and delete
ect.. and user name....)
Thanks
"Jason Massie" <jason**R3move**@.statisticsio.com> wrote in message
news:eAPgbG0mIHA.944@.TK2MSFTNGP05.phx.gbl...
>I don't of any free tools. As a matter of fact, they are pretty pricey
>since people are usually in a bind when they go looking for them. However,
>I believe they are just a gui on dbcc log so you could look into that
>command. It is pretty cryptic though.
> --
> Jason Massie
> Web: http://statisticsio.com
> RSS: http://feeds.feedburner.com/statisticsio
> "Mecn" <mecn@.yahoo.com> wrote in message
> news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
>> Hi,
>> I need to read sql2005 log files. Red gate has sql2000 one for free. I
>> need sql2005.
>> any ideas?
>> thanks
>|||On Thu, 10 Apr 2008 15:59:48 -0400, Mecn wrote:
> I tried. It desn't really tell me anything.
> What I need is that It shows the sql stetement (update, select and delete
> ect.. and user name....)
> Thanks
The log does not store sql statements. It only stores information regarding
changes that were made to pages in the database (i.e. were rows
inserted/updated/deleted).
Thanks,
Marcel van der Holst
SQL Server Storage Engine Team.
>
> "Jason Massie" <jason**R3move**@.statisticsio.com> wrote in message
> news:eAPgbG0mIHA.944@.TK2MSFTNGP05.phx.gbl...
>>I don't of any free tools. As a matter of fact, they are pretty pricey
>>since people are usually in a bind when they go looking for them. However,
>>I believe they are just a gui on dbcc log so you could look into that
>>command. It is pretty cryptic though.
>> --
>> Jason Massie
>> Web: http://statisticsio.com
>> RSS: http://feeds.feedburner.com/statisticsio
>> "Mecn" <mecn@.yahoo.com> wrote in message
>> news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
>> Hi,
>> I need to read sql2005 log files. Red gate has sql2000 one for free. I
>> need sql2005.
>> any ideas?
>> thanks
>>|||Pay the money (surprisingly little, actually) for apexsql.com's Log product.
Every production environment should have a tool such as this available for
the 'holy-shit' times. Also helps trememdously during
debugging/troubleshooting scenarios too.
Disclaimer: I work closely with Apex, I use and promote their products to
my clients. If you tell them TheSQLGuru sent you you can pick up a nice
discount (and I will receive a small referral fee). They have a wide array
of very useful SQL Server-specific tools.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Mecn" <mecn@.yahoo.com> wrote in message
news:Oa4fN9zmIHA.3532@.TK2MSFTNGP05.phx.gbl...
> Hi,
> I need to read sql2005 log files. Red gate has sql2000 one for free. I
> need sql2005.
> any ideas?
> thanks
>