Showing posts with label avoid. Show all posts
Showing posts with label avoid. Show all posts

Wednesday, March 28, 2012

Recovery Full vs Simple

Hi,
Once in a while I have to do a set of things to avoid the db halts in the
middle of the day to resize the log file as it grows. These are the ones in
the correct order:
1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
2) dbcc shrinkfile(MyDb_log,1)
3) ALTER DATABASE MyDb SET RECOVERY FULL
4) Then allocate a big junk of space for the log file to have enough buffer.
This operation can take a long time.
Is there an alternative to that? I already set up real-time replication and
full backup every night, so I'm also wondering what other benefits that the
log file set in full mode would give me, would someone know?
Thanks!!If you don't require log backups then set recovery mode permanently to
Simple. Set the log file size as big as you need it and then leave it alone.
The one thing NOT to do is regularly shrik the log. Doing so achieves
nothing except harm performance and probably bring your server to a halt.
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
--
David Portas
SQL Server MVP
--|||Zeng wrote:
> Hi,
> Once in a while I have to do a set of things to avoid the db halts in
> the middle of the day to resize the log file as it grows. These are
> the ones in the correct order:
> 1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
> 2) dbcc shrinkfile(MyDb_log,1)
> 3) ALTER DATABASE MyDb SET RECOVERY FULL
> 4) Then allocate a big junk of space for the log file to have enough
> buffer. This operation can take a long time.
> Is there an alternative to that? I already set up real-time
> replication and full backup every night, so I'm also wondering what
> other benefits that the log file set in full mode would give me,
> would someone know?
> Thanks!!
To add to what David said, once you go from Simple to Full recovery, you
have to immediately perform a full database backup to prevent the log
file from continuing to truncate.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||In which scenerios/reasons I should have log backups? thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> If you don't require log backups then set recovery mode permanently to
> Simple. Set the log file size as big as you need it and then leave it
alone.
> The one thing NOT to do is regularly shrik the log. Doing so achieves
> nothing except harm performance and probably bring your server to a halt.
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> --
> David Portas
> SQL Server MVP
> --
>|||Log backup allow things like:
More frequent backup. Like every 10 minutes or every hour.
Pint in time restore. When you restore from a log backup, you can STOPAT a specified time.
Backup the log of a damaged database.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> In which scenerios/reasons I should have log backups? thanks
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
>> If you don't require log backups then set recovery mode permanently to
>> Simple. Set the log file size as big as you need it and then leave it
> alone.
>> The one thing NOT to do is regularly shrik the log. Doing so achieves
>> nothing except harm performance and probably bring your server to a halt.
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>> --
>> David Portas
>> SQL Server MVP
>> --
>>
>|||It depends what level of recovery you need. If you believe backing up
once a day meets your needs then maybe you don't require transaction
log backups. In most OLTP scenarios however it's usually unacceptable
for the business to lose a day's work in the event of a disaster. Log
backups mean you can take much more frequent backups during the during
the day and therefore minimize the risk of data loss and downtime.
--
David Portas
SQL Server MVP
--|||If I have continuous replication set up, would it be any beneficial to me?
That is, is there a case where my replication db is bad that I need to
rollback/restore my db back to 10 min before the disaster happens?
thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> Log backup allow things like:
> More frequent backup. Like every 10 minutes or every hour.
> Pint in time restore. When you restore from a log backup, you can STOPAT a
specified time.
> Backup the log of a damaged database.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Zeng" <Zeng5000@.hotmail.com> wrote in message
news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> > In which scenerios/reasons I should have log backups? thanks
> >
> > "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> > news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> >> If you don't require log backups then set recovery mode permanently to
> >> Simple. Set the log file size as big as you need it and then leave it
> > alone.
> >> The one thing NOT to do is regularly shrik the log. Doing so achieves
> >> nothing except harm performance and probably bring your server to a
halt.
> >>
> >> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> >>
> >> --
> >> David Portas
> >> SQL Server MVP
> >> --
> >>
> >>
> >
> >|||I'm not sure I understand the question. Are you saying you want to use replication for some disaster
recovery scenario instead of backup? If so, don't. If you are looking for high avability, read
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/sqlhalp.mspx
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:ur59lcqdFHA.4040@.TK2MSFTNGP14.phx.gbl...
> If I have continuous replication set up, would it be any beneficial to me?
> That is, is there a case where my replication db is bad that I need to
> rollback/restore my db back to 10 min before the disaster happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
>> Log backup allow things like:
>> More frequent backup. Like every 10 minutes or every hour.
>> Pint in time restore. When you restore from a log backup, you can STOPAT a
> specified time.
>> Backup the log of a damaged database.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>> Blog: http://solidqualitylearning.com/blogs/tibor/
>>
>> "Zeng" <Zeng5000@.hotmail.com> wrote in message
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
>> > In which scenerios/reasons I should have log backups? thanks
>> >
>> > "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
>> > news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
>> >> If you don't require log backups then set recovery mode permanently to
>> >> Simple. Set the log file size as big as you need it and then leave it
>> > alone.
>> >> The one thing NOT to do is regularly shrik the log. Doing so achieves
>> >> nothing except harm performance and probably bring your server to a
> halt.
>> >>
>> >> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>> >>
>> >> --
>> >> David Portas
>> >> SQL Server MVP
>> >> --
>> >>
>> >>
>> >
>> >
>|||It might be worth that you read about Backup/Restore Architecture in Books
On Line. It seems like you are missing some basic knowledge about how backup
works - and why you need to backup...:-).
Using replication might be ok in the case where your database becomes
corrupt, but what if a user makes a mistake in the database? Then this
mistake will be replicated as well, so you can't recreate data from the
replicated database. If you have a backup you can restore to a point in time
and then get data from there.
Regards
Steen
Zeng wrote:
> If I have continuous replication set up, would it be any beneficial
> to me? That is, is there a case where my replication db is bad that I
> need to rollback/restore my db back to 10 min before the disaster
> happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
> wrote in message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
>> Log backup allow things like:
>> More frequent backup. Like every 10 minutes or every hour.
>> Pint in time restore. When you restore from a log backup, you can
>> STOPAT a specified time. Backup the log of a damaged database.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>> Blog: http://solidqualitylearning.com/blogs/tibor/
>>
>> "Zeng" <Zeng5000@.hotmail.com> wrote in message
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
>> In which scenerios/reasons I should have log backups? thanks
>> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in
>> message news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
>> If you don't require log backups then set recovery mode
>> permanently to Simple. Set the log file size as big as you need it
>> and then leave it alone. The one thing NOT to do is regularly
>> shrik the log. Doing so achieves nothing except harm performance
>> and probably bring your server to a halt.
>> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>> --
>> David Portas
>> SQL Server MVP
>> --|||we back up every night as well. Why would it be so important to recover user
mistake within the same day (smaller window of time -> less amount of work
to reconstruct)? If a computer user makes a mistake - such as overwriting a
file on their personal computer, there won't be much to recover, that's
widely accepted. If we have 1000 users and 10% of them eventually want to
recover their mistake, it would be messy. Maybe you are concerned about
system mistake/bug?
If I go to my bank and withdraw a money out of the checking account and
trigger a fee because it goes below certain balance threshold, nobody would
allow me to cover it.
Rolling back entire db to certain point in time and make it production db
won't work well either, there must have been many changes since that point
in time that won't be honored in the rollback.
"Steen Persson (DK)" <spe@.REMOVEdatea.dk> wrote in message
news:%23LUzwSydFHA.2776@.TK2MSFTNGP10.phx.gbl...
> It might be worth that you read about Backup/Restore Architecture in Books
> On Line. It seems like you are missing some basic knowledge about how
backup
> works - and why you need to backup...:-).
> Using replication might be ok in the case where your database becomes
> corrupt, but what if a user makes a mistake in the database? Then this
> mistake will be replicated as well, so you can't recreate data from the
> replicated database. If you have a backup you can restore to a point in
time
> and then get data from there.
> Regards
> Steen
> Zeng wrote:
> > If I have continuous replication set up, would it be any beneficial
> > to me? That is, is there a case where my replication db is bad that I
> > need to rollback/restore my db back to 10 min before the disaster
> > happens?
> >
> > thanks
> >
> > "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
> > wrote in message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> >> Log backup allow things like:
> >>
> >> More frequent backup. Like every 10 minutes or every hour.
> >> Pint in time restore. When you restore from a log backup, you can
> >> STOPAT a specified time. Backup the log of a damaged database.
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://www.solidqualitylearning.com/
> >> Blog: http://solidqualitylearning.com/blogs/tibor/
> >>
> >>
> >> "Zeng" <Zeng5000@.hotmail.com> wrote in message
> > news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> >> In which scenerios/reasons I should have log backups? thanks
> >>
> >> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in
> >> message news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> >> If you don't require log backups then set recovery mode
> >> permanently to Simple. Set the log file size as big as you need it
> >> and then leave it alone. The one thing NOT to do is regularly
> >> shrik the log. Doing so achieves nothing except harm performance
> >> and probably bring your server to a halt.
> >>
> >> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> >>
> >> --
> >> David Portas
> >> SQL Server MVP
> >> --
>|||Generally, you don't use backups to recovery from plain user mistakes. If a user deletes an order,
that user call up the customer, admits the mistake and re-enter the order. And learn from that. Or,
in reality use some logged information by the app or on paper to recover.
What you protect is from things like deleting a table by mistake. Or deleting all rows in a table by
mistake. The problem with undoing only certain operations in a database is that the database has a
state from two different points in time. And one operations can very well be depending on another
operation. "We wouldn't have allowed this loan if it weren't for..." I.e., you have an inconsistent
database. You will only allow this if you know your data *very* well.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:OiAZWU1dFHA.1384@.TK2MSFTNGP09.phx.gbl...
> we back up every night as well. Why would it be so important to recover user
> mistake within the same day (smaller window of time -> less amount of work
> to reconstruct)? If a computer user makes a mistake - such as overwriting a
> file on their personal computer, there won't be much to recover, that's
> widely accepted. If we have 1000 users and 10% of them eventually want to
> recover their mistake, it would be messy. Maybe you are concerned about
> system mistake/bug?
> If I go to my bank and withdraw a money out of the checking account and
> trigger a fee because it goes below certain balance threshold, nobody would
> allow me to cover it.
> Rolling back entire db to certain point in time and make it production db
> won't work well either, there must have been many changes since that point
> in time that won't be honored in the rollback.
>
> "Steen Persson (DK)" <spe@.REMOVEdatea.dk> wrote in message
> news:%23LUzwSydFHA.2776@.TK2MSFTNGP10.phx.gbl...
>> It might be worth that you read about Backup/Restore Architecture in Books
>> On Line. It seems like you are missing some basic knowledge about how
> backup
>> works - and why you need to backup...:-).
>> Using replication might be ok in the case where your database becomes
>> corrupt, but what if a user makes a mistake in the database? Then this
>> mistake will be replicated as well, so you can't recreate data from the
>> replicated database. If you have a backup you can restore to a point in
> time
>> and then get data from there.
>> Regards
>> Steen
>> Zeng wrote:
>> > If I have continuous replication set up, would it be any beneficial
>> > to me? That is, is there a case where my replication db is bad that I
>> > need to rollback/restore my db back to 10 min before the disaster
>> > happens?
>> >
>> > thanks
>> >
>> > "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
>> > wrote in message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
>> >> Log backup allow things like:
>> >>
>> >> More frequent backup. Like every 10 minutes or every hour.
>> >> Pint in time restore. When you restore from a log backup, you can
>> >> STOPAT a specified time. Backup the log of a damaged database.
>> >>
>> >> --
>> >> Tibor Karaszi, SQL Server MVP
>> >> http://www.karaszi.com/sqlserver/default.asp
>> >> http://www.solidqualitylearning.com/
>> >> Blog: http://solidqualitylearning.com/blogs/tibor/
>> >>
>> >>
>> >> "Zeng" <Zeng5000@.hotmail.com> wrote in message
>> > news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
>> >> In which scenerios/reasons I should have log backups? thanks
>> >>
>> >> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in
>> >> message news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
>> >> If you don't require log backups then set recovery mode
>> >> permanently to Simple. Set the log file size as big as you need it
>> >> and then leave it alone. The one thing NOT to do is regularly
>> >> shrik the log. Doing so achieves nothing except harm performance
>> >> and probably bring your server to a halt.
>> >>
>> >> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
>> >>
>> >> --
>> >> David Portas
>> >> SQL Server MVP
>> >> --
>>
>sql

Monday, March 26, 2012

Recovery Full vs Simple

Hi,
Once in a while I have to do a set of things to avoid the db halts in the
middle of the day to resize the log file as it grows. These are the ones in
the correct order:
1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
2) dbcc shrinkfile(MyDb_log,1)
3) ALTER DATABASE MyDb SET RECOVERY FULL
4) Then allocate a big junk of space for the log file to have enough buffer.
This operation can take a long time.
Is there an alternative to that? I already set up real-time replication and
full backup every night, so I'm also wondering what other benefits that the
log file set in full mode would give me, would someone know?
Thanks!!
If you don't require log backups then set recovery mode permanently to
Simple. Set the log file size as big as you need it and then leave it alone.
The one thing NOT to do is regularly shrik the log. Doing so achieves
nothing except harm performance and probably bring your server to a halt.
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
David Portas
SQL Server MVP
|||Zeng wrote:
> Hi,
> Once in a while I have to do a set of things to avoid the db halts in
> the middle of the day to resize the log file as it grows. These are
> the ones in the correct order:
> 1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
> 2) dbcc shrinkfile(MyDb_log,1)
> 3) ALTER DATABASE MyDb SET RECOVERY FULL
> 4) Then allocate a big junk of space for the log file to have enough
> buffer. This operation can take a long time.
> Is there an alternative to that? I already set up real-time
> replication and full backup every night, so I'm also wondering what
> other benefits that the log file set in full mode would give me,
> would someone know?
> Thanks!!
To add to what David said, once you go from Simple to Full recovery, you
have to immediately perform a full database backup to prevent the log
file from continuing to truncate.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||In which scenerios/reasons I should have log backups? thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> If you don't require log backups then set recovery mode permanently to
> Simple. Set the log file size as big as you need it and then leave it
alone.
> The one thing NOT to do is regularly shrik the log. Doing so achieves
> nothing except harm performance and probably bring your server to a halt.
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> --
> David Portas
> SQL Server MVP
> --
>
|||Log backup allow things like:
More frequent backup. Like every 10 minutes or every hour.
Pint in time restore. When you restore from a log backup, you can STOPAT a specified time.
Backup the log of a damaged database.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> In which scenerios/reasons I should have log backups? thanks
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> alone.
>
|||It depends what level of recovery you need. If you believe backing up
once a day meets your needs then maybe you don't require transaction
log backups. In most OLTP scenarios however it's usually unacceptable
for the business to lose a day's work in the event of a disaster. Log
backups mean you can take much more frequent backups during the during
the day and therefore minimize the risk of data loss and downtime.
David Portas
SQL Server MVP
|||If I have continuous replication set up, would it be any beneficial to me?
That is, is there a case where my replication db is bad that I need to
rollback/restore my db back to 10 min before the disaster happens?
thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> Log backup allow things like:
> More frequent backup. Like every 10 minutes or every hour.
> Pint in time restore. When you restore from a log backup, you can STOPAT a
specified time.
> Backup the log of a damaged database.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Zeng" <Zeng5000@.hotmail.com> wrote in message
news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
halt.[vbcol=seagreen]
|||I'm not sure I understand the question. Are you saying you want to use replication for some disaster
recovery scenario instead of backup? If so, don't. If you are looking for high avability, read
http://www.microsoft.com/technet/pro...y/sqlhalp.mspx
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:ur59lcqdFHA.4040@.TK2MSFTNGP14.phx.gbl...
> If I have continuous replication set up, would it be any beneficial to me?
> That is, is there a case where my replication db is bad that I need to
> rollback/restore my db back to 10 min before the disaster happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> specified time.
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> halt.
>
|||It might be worth that you read about Backup/Restore Architecture in Books
On Line. It seems like you are missing some basic knowledge about how backup
works - and why you need to backup...:-).
Using replication might be ok in the case where your database becomes
corrupt, but what if a user makes a mistake in the database? Then this
mistake will be replicated as well, so you can't recreate data from the
replicated database. If you have a backup you can restore to a point in time
and then get data from there.
Regards
Steen
Zeng wrote:[vbcol=seagreen]
> If I have continuous replication set up, would it be any beneficial
> to me? That is, is there a case where my replication db is bad that I
> need to rollback/restore my db back to 10 min before the disaster
> happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
> wrote in message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
|||we back up every night as well. Why would it be so important to recover user
mistake within the same day (smaller window of time -> less amount of work
to reconstruct)? If a computer user makes a mistake - such as overwriting a
file on their personal computer, there won't be much to recover, that's
widely accepted. If we have 1000 users and 10% of them eventually want to
recover their mistake, it would be messy. Maybe you are concerned about
system mistake/bug?
If I go to my bank and withdraw a money out of the checking account and
trigger a fee because it goes below certain balance threshold, nobody would
allow me to cover it.
Rolling back entire db to certain point in time and make it production db
won't work well either, there must have been many changes since that point
in time that won't be honored in the rollback.
"Steen Persson (DK)" <spe@.REMOVEdatea.dk> wrote in message
news:%23LUzwSydFHA.2776@.TK2MSFTNGP10.phx.gbl...
> It might be worth that you read about Backup/Restore Architecture in Books
> On Line. It seems like you are missing some basic knowledge about how
backup
> works - and why you need to backup...:-).
> Using replication might be ok in the case where your database becomes
> corrupt, but what if a user makes a mistake in the database? Then this
> mistake will be replicated as well, so you can't recreate data from the
> replicated database. If you have a backup you can restore to a point in
time
> and then get data from there.
> Regards
> Steen
> Zeng wrote:
>

Recovery Full vs Simple

Hi,
Once in a while I have to do a set of things to avoid the db halts in the
middle of the day to resize the log file as it grows. These are the ones in
the correct order:
1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
2) dbcc shrinkfile(MyDb_log,1)
3) ALTER DATABASE MyDb SET RECOVERY FULL
4) Then allocate a big junk of space for the log file to have enough buffer.
This operation can take a long time.
Is there an alternative to that? I already set up real-time replication and
full backup every night, so I'm also wondering what other benefits that the
log file set in full mode would give me, would someone know?
Thanks!!If you don't require log backups then set recovery mode permanently to
Simple. Set the log file size as big as you need it and then leave it alone.
The one thing NOT to do is regularly shrik the log. Doing so achieves
nothing except harm performance and probably bring your server to a halt.
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
David Portas
SQL Server MVP
--|||Zeng wrote:
> Hi,
> Once in a while I have to do a set of things to avoid the db halts in
> the middle of the day to resize the log file as it grows. These are
> the ones in the correct order:
> 1) ALTER DATABASE MyDb SET RECOVERY SIMPLE
> 2) dbcc shrinkfile(MyDb_log,1)
> 3) ALTER DATABASE MyDb SET RECOVERY FULL
> 4) Then allocate a big junk of space for the log file to have enough
> buffer. This operation can take a long time.
> Is there an alternative to that? I already set up real-time
> replication and full backup every night, so I'm also wondering what
> other benefits that the log file set in full mode would give me,
> would someone know?
> Thanks!!
To add to what David said, once you go from Simple to Full recovery, you
have to immediately perform a full database backup to prevent the log
file from continuing to truncate.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||In which scenerios/reasons I should have log backups? thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> If you don't require log backups then set recovery mode permanently to
> Simple. Set the log file size as big as you need it and then leave it
alone.
> The one thing NOT to do is regularly shrik the log. Doing so achieves
> nothing except harm performance and probably bring your server to a halt.
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> --
> David Portas
> SQL Server MVP
> --
>|||Log backup allow things like:
More frequent backup. Like every 10 minutes or every hour.
Pint in time restore. When you restore from a log backup, you can STOPAT a s
pecified time.
Backup the log of a damaged database.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl.
.
> In which scenerios/reasons I should have log backups? thanks
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:VY2dnZpdAtWA1CrfRVn-sw@.giganews.com...
> alone.
>|||It depends what level of recovery you need. If you believe backing up
once a day meets your needs then maybe you don't require transaction
log backups. In most OLTP scenarios however it's usually unacceptable
for the business to lose a day's work in the event of a disaster. Log
backups mean you can take much more frequent backups during the during
the day and therefore minimize the risk of data loss and downtime.
David Portas
SQL Server MVP
--|||If I have continuous replication set up, would it be any beneficial to me?
That is, is there a case where my replication db is bad that I need to
rollback/restore my db back to 10 min before the disaster happens?
thanks
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> Log backup allow things like:
> More frequent backup. Like every 10 minutes or every hour.
> Pint in time restore. When you restore from a log backup, you can STOPAT a
specified time.
> Backup the log of a damaged database.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Zeng" <Zeng5000@.hotmail.com> wrote in message
news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
halt.[vbcol=seagreen]|||I'm not sure I understand the question. Are you saying you want to use repli
cation for some disaster
recovery scenario instead of backup? If so, don't. If you are looking for hi
gh avability, read
http://www.microsoft.com/technet/pr...oy/sqlhalp.mspx
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Zeng" <Zeng5000@.hotmail.com> wrote in message news:ur59lcqdFHA.4040@.TK2MSFTNGP14.phx.gbl...

> If I have continuous replication set up, would it be any beneficial to me?
> That is, is there a case where my replication db is bad that I need to
> rollback/restore my db back to 10 min before the disaster happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n
> message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> specified time.
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...
> halt.
>|||It might be worth that you read about Backup/Restore Architecture in Books
On Line. It seems like you are missing some basic knowledge about how backup
works - and why you need to backup...:-).
Using replication might be ok in the case where your database becomes
corrupt, but what if a user makes a mistake in the database? Then this
mistake will be replicated as well, so you can't recreate data from the
replicated database. If you have a backup you can restore to a point in time
and then get data from there.
Regards
Steen
Zeng wrote:[vbcol=seagreen]
> If I have continuous replication set up, would it be any beneficial
> to me? That is, is there a case where my replication db is bad that I
> need to rollback/restore my db back to 10 min before the disaster
> happens?
> thanks
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com>
> wrote in message news:OdGFl0idFHA.960@.TK2MSFTNGP10.phx.gbl...
> news:uC%237rVfdFHA.1456@.TK2MSFTNGP15.phx.gbl...|||we back up every night as well. Why would it be so important to recover user
mistake within the same day (smaller window of time -> less amount of work
to reconstruct)? If a computer user makes a mistake - such as overwriting a
file on their personal computer, there won't be much to recover, that's
widely accepted. If we have 1000 users and 10% of them eventually want to
recover their mistake, it would be messy. Maybe you are concerned about
system mistake/bug?
If I go to my bank and withdraw a money out of the checking account and
trigger a fee because it goes below certain balance threshold, nobody would
allow me to cover it.
Rolling back entire db to certain point in time and make it production db
won't work well either, there must have been many changes since that point
in time that won't be honored in the rollback.
"Steen Persson (DK)" <spe@.REMOVEdatea.dk> wrote in message
news:%23LUzwSydFHA.2776@.TK2MSFTNGP10.phx.gbl...
> It might be worth that you read about Backup/Restore Architecture in Books
> On Line. It seems like you are missing some basic knowledge about how
backup
> works - and why you need to backup...:-).
> Using replication might be ok in the case where your database becomes
> corrupt, but what if a user makes a mistake in the database? Then this
> mistake will be replicated as well, so you can't recreate data from the
> replicated database. If you have a backup you can restore to a point in
time
> and then get data from there.
> Regards
> Steen
> Zeng wrote:
>

Wednesday, March 21, 2012

recovering database from expired trial version

Dear SQL Server experts,
I'm in a little pickle here, and hope I can avoid trashing many hours of
work. Here's the scenario:
I was running SQL Server 7 on Win2K Server, with several database projects
in development . I installed the 120-day trial version of SQL2000 with the
intention of installing Windows Small Business Server 2003 Premium (which
includes licensed SQL2000) before the end of the trial period. Well, the 120
days came and went, and the SQL2000 installation will, of course, no longer
run. The databases that had been converted to SQL2000 and further developed
were not detached or recently backed up prior to the expiration.
I fear that just installing the new OS with SQL2000 may result in the
permanent loss of the work since last backup. If there's a way to
re-activate the existing SQL2000 installation, hopefully without purchasing
the standard stand-alone SQL2000, my work may be saved. Any recommendations
for a course of action would be appreciated.
Thank you.Hi,
I think you should not use trial versions for business purposes. I know
most of us do it but you should not say it in public. try to keep it a
secret...|||Hi,
i would suggest you to uninstall the SQL Server trial version and purchase a
licensed copy.
you just need to install the licensed copy of SQL Server.
After that, you may need to locate your data file (for your previous database)
(For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
Then, open your Enterprise Manager, attach the database file.
hope this will help.
Leo
"Paul Deneen" wrote:
> Dear SQL Server experts,
> I'm in a little pickle here, and hope I can avoid trashing many hours of
> work. Here's the scenario:
> I was running SQL Server 7 on Win2K Server, with several database projects
> in development . I installed the 120-day trial version of SQL2000 with the
> intention of installing Windows Small Business Server 2003 Premium (which
> includes licensed SQL2000) before the end of the trial period. Well, the 120
> days came and went, and the SQL2000 installation will, of course, no longer
> run. The databases that had been converted to SQL2000 and further developed
> were not detached or recently backed up prior to the expiration.
> I fear that just installing the new OS with SQL2000 may result in the
> permanent loss of the work since last backup. If there's a way to
> re-activate the existing SQL2000 installation, hopefully without purchasing
> the standard stand-alone SQL2000, my work may be saved. Any recommendations
> for a course of action would be appreciated.
> Thank you.
>
>|||Mr. Leong,
Thank you. I didn't think that a database could be attached to a SQL
Server installation unless it had previously been "detached" with
sp_detach_db or had been backed up. I have always found it necessary to
detach the db in order to make a MDF file portable.
You don't have any reservations about recommending me to go ahead and
uninstall the trial SQL2000?
Thanks again.
"Leo Leong" wrote:
> Hi,
> i would suggest you to uninstall the SQL Server trial version and purchase a
> licensed copy.
> you just need to install the licensed copy of SQL Server.
> After that, you may need to locate your data file (for your previous database)
> (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
> Then, open your Enterprise Manager, attach the database file.
> hope this will help.
> Leo
> "Paul Deneen" wrote:
> >
> > Dear SQL Server experts,
> >
> > I'm in a little pickle here, and hope I can avoid trashing many hours of
> > work. Here's the scenario:
> > I was running SQL Server 7 on Win2K Server, with several database projects
> > in development . I installed the 120-day trial version of SQL2000 with the
> > intention of installing Windows Small Business Server 2003 Premium (which
> > includes licensed SQL2000) before the end of the trial period. Well, the 120
> > days came and went, and the SQL2000 installation will, of course, no longer
> > run. The databases that had been converted to SQL2000 and further developed
> > were not detached or recently backed up prior to the expiration.
> >
> > I fear that just installing the new OS with SQL2000 may result in the
> > permanent loss of the work since last backup. If there's a way to
> > re-activate the existing SQL2000 installation, hopefully without purchasing
> > the standard stand-alone SQL2000, my work may be saved. Any recommendations
> > for a course of action would be appreciated.
> >
> > Thank you.
> >
> >
> >|||Hi,
Since your MDF file is still there, you should be able to attach it after
installation.
I have tried once with no problem at all. unless those user logins in my MDF
didn't exist in the database server that I attached to.
May be you have other input. Would you like to share? thanks.
Uninstallation of your current trial version is neccesary. For development,
normally I will get a Developer Edition of SQL Server.
Leo
"Paul Deneen" wrote:
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
> > Hi,
> >
> > i would suggest you to uninstall the SQL Server trial version and purchase a
> > licensed copy.
> > you just need to install the licensed copy of SQL Server.
> > After that, you may need to locate your data file (for your previous database)
> > (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
> > Then, open your Enterprise Manager, attach the database file.
> >
> > hope this will help.
> >
> > Leo
> >
> > "Paul Deneen" wrote:
> >
> > >
> > > Dear SQL Server experts,
> > >
> > > I'm in a little pickle here, and hope I can avoid trashing many hours of
> > > work. Here's the scenario:
> > > I was running SQL Server 7 on Win2K Server, with several database projects
> > > in development . I installed the 120-day trial version of SQL2000 with the
> > > intention of installing Windows Small Business Server 2003 Premium (which
> > > includes licensed SQL2000) before the end of the trial period. Well, the 120
> > > days came and went, and the SQL2000 installation will, of course, no longer
> > > run. The databases that had been converted to SQL2000 and further developed
> > > were not detached or recently backed up prior to the expiration.
> > >
> > > I fear that just installing the new OS with SQL2000 may result in the
> > > permanent loss of the work since last backup. If there's a way to
> > > re-activate the existing SQL2000 installation, hopefully without purchasing
> > > the standard stand-alone SQL2000, my work may be saved. Any recommendations
> > > for a course of action would be appreciated.
> > >
> > > Thank you.
> > >
> > >
> > >|||It is correct that you are not guaranteed to be able to attach if you don't detach first. Books
Online also states this explicitly. In most cases it will work, but we regularly see posts here from
people where it doesn't work. To play safe, also do backup of those databases, so you then have an
option to restore, if attach doesn't work.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
>> Hi,
>> i would suggest you to uninstall the SQL Server trial version and purchase a
>> licensed copy.
>> you just need to install the licensed copy of SQL Server.
>> After that, you may need to locate your data file (for your previous database)
>> (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
>> Then, open your Enterprise Manager, attach the database file.
>> hope this will help.
>> Leo
>> "Paul Deneen" wrote:
>> >
>> > Dear SQL Server experts,
>> >
>> > I'm in a little pickle here, and hope I can avoid trashing many hours of
>> > work. Here's the scenario:
>> > I was running SQL Server 7 on Win2K Server, with several database projects
>> > in development . I installed the 120-day trial version of SQL2000 with the
>> > intention of installing Windows Small Business Server 2003 Premium (which
>> > includes licensed SQL2000) before the end of the trial period. Well, the 120
>> > days came and went, and the SQL2000 installation will, of course, no longer
>> > run. The databases that had been converted to SQL2000 and further developed
>> > were not detached or recently backed up prior to the expiration.
>> >
>> > I fear that just installing the new OS with SQL2000 may result in the
>> > permanent loss of the work since last backup. If there's a way to
>> > re-activate the existing SQL2000 installation, hopefully without purchasing
>> > the standard stand-alone SQL2000, my work may be saved. Any recommendations
>> > for a course of action would be appreciated.
>> >
>> > Thank you.
>> >
>> >
>> >|||Thank you Mr. Karaszi and Mr. Leong,
I'll have to uninstall SQL2000 and hope for the best on re-attaching the DB,
since I can't backup using the expired trial installation.
Again, thank you for your advice.
-Paul
"Tibor Karaszi" wrote:
> It is correct that you are not guaranteed to be able to attach if you don't detach first. Books
> Online also states this explicitly. In most cases it will work, but we regularly see posts here from
> people where it doesn't work. To play safe, also do backup of those databases, so you then have an
> option to restore, if attach doesn't work.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
> news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...
> > Mr. Leong,
> >
> > Thank you. I didn't think that a database could be attached to a SQL
> > Server installation unless it had previously been "detached" with
> > sp_detach_db or had been backed up. I have always found it necessary to
> > detach the db in order to make a MDF file portable.
> >
> > You don't have any reservations about recommending me to go ahead and
> > uninstall the trial SQL2000?
> >
> > Thanks again.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > "Leo Leong" wrote:
> >
> >> Hi,
> >>
> >> i would suggest you to uninstall the SQL Server trial version and purchase a
> >> licensed copy.
> >> you just need to install the licensed copy of SQL Server.
> >> After that, you may need to locate your data file (for your previous database)
> >> (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
> >> Then, open your Enterprise Manager, attach the database file.
> >>
> >> hope this will help.
> >>
> >> Leo
> >>
> >> "Paul Deneen" wrote:
> >>
> >> >
> >> > Dear SQL Server experts,
> >> >
> >> > I'm in a little pickle here, and hope I can avoid trashing many hours of
> >> > work. Here's the scenario:
> >> > I was running SQL Server 7 on Win2K Server, with several database projects
> >> > in development . I installed the 120-day trial version of SQL2000 with the
> >> > intention of installing Windows Small Business Server 2003 Premium (which
> >> > includes licensed SQL2000) before the end of the trial period. Well, the 120
> >> > days came and went, and the SQL2000 installation will, of course, no longer
> >> > run. The databases that had been converted to SQL2000 and further developed
> >> > were not detached or recently backed up prior to the expiration.
> >> >
> >> > I fear that just installing the new OS with SQL2000 may result in the
> >> > permanent loss of the work since last backup. If there's a way to
> >> > re-activate the existing SQL2000 installation, hopefully without purchasing
> >> > the standard stand-alone SQL2000, my work may be saved. Any recommendations
> >> > for a course of action would be appreciated.
> >> >
> >> > Thank you.
> >> >
> >> >
> >> >
>

recovering database from expired trial version

Dear SQL Server experts,
I'm in a little pickle here, and hope I can avoid trashing many hours of
work. Here's the scenario:
I was running SQL Server 7 on Win2K Server, with several database projects
in development . I installed the 120-day trial version of SQL2000 with the
intention of installing Windows Small Business Server 2003 Premium (which
includes licensed SQL2000) before the end of the trial period. Well, the 120
days came and went, and the SQL2000 installation will, of course, no longer
run. The databases that had been converted to SQL2000 and further developed
were not detached or recently backed up prior to the expiration.
I fear that just installing the new OS with SQL2000 may result in the
permanent loss of the work since last backup. If there's a way to
re-activate the existing SQL2000 installation, hopefully without purchasing
the standard stand-alone SQL2000, my work may be saved. Any recommendations
for a course of action would be appreciated.
Thank you.
Hi,
I think you should not use trial versions for business purposes. I know
most of us do it but you should not say it in public. try to keep it a
secret...
|||Hi,
i would suggest you to uninstall the SQL Server trial version and purchase a
licensed copy.
you just need to install the licensed copy of SQL Server.
After that, you may need to locate your data file (for your previous database)
(For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
Then, open your Enterprise Manager, attach the database file.
hope this will help.
Leo
"Paul Deneen" wrote:

> Dear SQL Server experts,
> I'm in a little pickle here, and hope I can avoid trashing many hours of
> work. Here's the scenario:
> I was running SQL Server 7 on Win2K Server, with several database projects
> in development . I installed the 120-day trial version of SQL2000 with the
> intention of installing Windows Small Business Server 2003 Premium (which
> includes licensed SQL2000) before the end of the trial period. Well, the 120
> days came and went, and the SQL2000 installation will, of course, no longer
> run. The databases that had been converted to SQL2000 and further developed
> were not detached or recently backed up prior to the expiration.
> I fear that just installing the new OS with SQL2000 may result in the
> permanent loss of the work since last backup. If there's a way to
> re-activate the existing SQL2000 installation, hopefully without purchasing
> the standard stand-alone SQL2000, my work may be saved. Any recommendations
> for a course of action would be appreciated.
> Thank you.
>
>
|||Mr. Leong,
Thank you. I didn't think that a database could be attached to a SQL
Server installation unless it had previously been "detached" with
sp_detach_db or had been backed up. I have always found it necessary to
detach the db in order to make a MDF file portable.
You don't have any reservations about recommending me to go ahead and
uninstall the trial SQL2000?
Thanks again.
"Leo Leong" wrote:
[vbcol=seagreen]
> Hi,
> i would suggest you to uninstall the SQL Server trial version and purchase a
> licensed copy.
> you just need to install the licensed copy of SQL Server.
> After that, you may need to locate your data file (for your previous database)
> (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
> Then, open your Enterprise Manager, attach the database file.
> hope this will help.
> Leo
> "Paul Deneen" wrote:
|||Hi,
Since your MDF file is still there, you should be able to attach it after
installation.
I have tried once with no problem at all. unless those user logins in my MDF
didn't exist in the database server that I attached to.
May be you have other input. Would you like to share? thanks.
Uninstallation of your current trial version is neccesary. For development,
normally I will get a Developer Edition of SQL Server.
Leo
"Paul Deneen" wrote:
[vbcol=seagreen]
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
|||It is correct that you are not guaranteed to be able to attach if you don't detach first. Books
Online also states this explicitly. In most cases it will work, but we regularly see posts here from
people where it doesn't work. To play safe, also do backup of those databases, so you then have an
option to restore, if attach doesn't work.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...[vbcol=seagreen]
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
|||Thank you Mr. Karaszi and Mr. Leong,
I'll have to uninstall SQL2000 and hope for the best on re-attaching the DB,
since I can't backup using the expired trial installation.
Again, thank you for your advice.
-Paul
"Tibor Karaszi" wrote:

> It is correct that you are not guaranteed to be able to attach if you don't detach first. Books
> Online also states this explicitly. In most cases it will work, but we regularly see posts here from
> people where it doesn't work. To play safe, also do backup of those databases, so you then have an
> option to restore, if attach doesn't work.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
> news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...
>

recovering database from expired trial version

Dear SQL Server experts,
I'm in a little pickle here, and hope I can avoid trashing many hours of
work. Here's the scenario:
I was running SQL Server 7 on Win2K Server, with several database projects
in development . I installed the 120-day trial version of SQL2000 with the
intention of installing Windows Small Business Server 2003 Premium (which
includes licensed SQL2000) before the end of the trial period. Well, the 120
days came and went, and the SQL2000 installation will, of course, no longer
run. The databases that had been converted to SQL2000 and further develope
d
were not detached or recently backed up prior to the expiration.
I fear that just installing the new OS with SQL2000 may result in the
permanent loss of the work since last backup. If there's a way to
re-activate the existing SQL2000 installation, hopefully without purchasing
the standard stand-alone SQL2000, my work may be saved. Any recommendations
for a course of action would be appreciated.
Thank you.Hi,
I think you should not use trial versions for business purposes. I know
most of us do it but you should not say it in public. try to keep it a
secret...|||Hi,
i would suggest you to uninstall the SQL Server trial version and purchase a
licensed copy.
you just need to install the licensed copy of SQL Server.
After that, you may need to locate your data file (for your previous databas
e)
(For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
Then, open your Enterprise Manager, attach the database file.
hope this will help.
Leo
"Paul Deneen" wrote:

> Dear SQL Server experts,
> I'm in a little pickle here, and hope I can avoid trashing many hours of
> work. Here's the scenario:
> I was running SQL Server 7 on Win2K Server, with several database projects
> in development . I installed the 120-day trial version of SQL2000 with th
e
> intention of installing Windows Small Business Server 2003 Premium (which
> includes licensed SQL2000) before the end of the trial period. Well, the 1
20
> days came and went, and the SQL2000 installation will, of course, no longe
r
> run. The databases that had been converted to SQL2000 and further develo
ped
> were not detached or recently backed up prior to the expiration.
> I fear that just installing the new OS with SQL2000 may result in the
> permanent loss of the work since last backup. If there's a way to
> re-activate the existing SQL2000 installation, hopefully without purchasi
ng
> the standard stand-alone SQL2000, my work may be saved. Any recommendatio
ns
> for a course of action would be appreciated.
> Thank you.
>
>|||Mr. Leong,
Thank you. I didn't think that a database could be attached to a SQL
Server installation unless it had previously been "detached" with
sp_detach_db or had been backed up. I have always found it necessary to
detach the db in order to make a MDF file portable.
You don't have any reservations about recommending me to go ahead and
uninstall the trial SQL2000?
Thanks again.
"Leo Leong" wrote:
[vbcol=seagreen]
> Hi,
> i would suggest you to uninstall the SQL Server trial version and purchase
a
> licensed copy.
> you just need to install the licensed copy of SQL Server.
> After that, you may need to locate your data file (for your previous datab
ase)
> (For example: C:\program files\Microsoft SQL Server\MSSQL\Data)
> Then, open your Enterprise Manager, attach the database file.
> hope this will help.
> Leo
> "Paul Deneen" wrote:
>|||Hi,
Since your MDF file is still there, you should be able to attach it after
installation.
I have tried once with no problem at all. unless those user logins in my MDF
didn't exist in the database server that I attached to.
May be you have other input. Would you like to share? thanks.
Uninstallation of your current trial version is neccesary. For development,
normally I will get a Developer Edition of SQL Server.
Leo
"Paul Deneen" wrote:
[vbcol=seagreen]
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
>|||It is correct that you are not guaranteed to be able to attach if you don't
detach first. Books
Online also states this explicitly. In most cases it will work, but we regul
arly see posts here from
people where it doesn't work. To play safe, also do backup of those database
s, so you then have an
option to restore, if attach doesn't work.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...[vbcol=seagreen]
> Mr. Leong,
> Thank you. I didn't think that a database could be attached to a SQL
> Server installation unless it had previously been "detached" with
> sp_detach_db or had been backed up. I have always found it necessary to
> detach the db in order to make a MDF file portable.
> You don't have any reservations about recommending me to go ahead and
> uninstall the trial SQL2000?
> Thanks again.
>
>
>
>
> "Leo Leong" wrote:
>|||Thank you Mr. Karaszi and Mr. Leong,
I'll have to uninstall SQL2000 and hope for the best on re-attaching the DB,
since I can't backup using the expired trial installation.
Again, thank you for your advice.
-Paul
"Tibor Karaszi" wrote:

> It is correct that you are not guaranteed to be able to attach if you don'
t detach first. Books
> Online also states this explicitly. In most cases it will work, but we reg
ularly see posts here from
> people where it doesn't work. To play safe, also do backup of those databa
ses, so you then have an
> option to restore, if attach doesn't work.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Paul Deneen" <PaulDeneen@.discussions.microsoft.com> wrote in message
> news:858AD928-3B01-4B56-BB31-4B06E270D41E@.microsoft.com...
>