Pardon my long windedness, but I want to provide a full explanation.
I have very limited (next to none) knowledge of SQL Server or NT / 2000
Server.
We had a membership database stored on an SQL Server 6.5 on an NT system.
We accessed it via a custom written Visual Basic program called Member. The
computer crashed, not the drive. Apparently, it was an old single processor
PC. I tried to move the drive into a newer computer and got a HAL.DLL
error. I was able to recover the DAT files using the drive as a second dive
on a newer PC.
I put the drive in a newer computer and upgraded it to Windows 2000. Then I
reinstalled SQL Server 6.5. I created the matching database and database
devices. I then copied the old DAT files over and it worked. I was able to
access the old database files. Hooray!
I reinstalled the Member program, and sure enough the connection strings
work and I can access my data again. Another Hooray!
Now my only problem is that I cannot connect to the database from any of the
network computers, only locally. I have read many pages on the internet and
experimented quite a bit, but I still get an ODBC timeout failure every time
I try to connect from one of the other computers on the network.
It appears that my SQL is running and sharing the information, but only
locally. Or there is some other reason that I cannot access it over the
network? Any ideas? I really need to get this up and running again soon.
Thanks for any help.
TedDid you enabled the TCP/IP protocol while installing the SQL Server 6.5? If
not go to SQL 6.5 Setup program
and check if the TCP/IP is selected; else include that and try connecting.
Its been a long time I have worked with
SQL 6.5.
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.gi
ganews.com...
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member.
> The computer crashed, not the drive. Apparently, it was an old single
> processor PC. I tried to move the drive into a newer computer and got a
> HAL.DLL error. I was able to recover the DAT files using the drive as a
> second dive on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then
> I reinstalled SQL Server 6.5. I created the matching database and
> database devices. I then copied the old DAT files over and it worked. I
> was able to access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of
> the network computers, only locally. I have read many pages on the
> internet and experimented quite a bit, but I still get an ODBC timeout
> failure every time I try to connect from one of the other computers on the
> network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>|||Hi Ted
Just wondering if you changed the name of the server, in which case you may
need to change the connection properties for the application.
John
"Ted Hadley" wrote:
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member. T
he
> computer crashed, not the drive. Apparently, it was an old single process
or
> PC. I tried to move the drive into a newer computer and got a HAL.DLL
> error. I was able to recover the DAT files using the drive as a second di
ve
> on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then
I
> reinstalled SQL Server 6.5. I created the matching database and database
> devices. I then copied the old DAT files over and it worked. I was able
to
> access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of t
he
> network computers, only locally. I have read many pages on the internet a
nd
> experimented quite a bit, but I still get an ODBC timeout failure every ti
me
> I try to connect from one of the other computers on the network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>
>|||That was exactly the problem. Thank you Hari. I ran the Setup program,
checked TCP/IP, and restarted SQL. It worked immediately.
You're a lifesaver!
Ted
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
> Did you enabled the TCP/IP protocol while installing the SQL Server 6.5?
> If not go to SQL 6.5 Setup program
> and check if the TCP/IP is selected; else include that and try connecting.
> Its been a long time I have worked with
> SQL 6.5.
> Thanks
> Hari
> SQL Server MVP
>
> "Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
> news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.gi
ganews.com...
>|||Thats a good news..
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:6a-dnUP6fbGi53LZnZ2dnUVZ_sydnZ2d@.giganews.com...
> That was exactly the problem. Thank you Hari. I ran the Setup program,
> checked TCP/IP, and restarted SQL. It worked immediately.
> You're a lifesaver!
> Ted
> "Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
> news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
>sql
Showing posts with label limited. Show all posts
Showing posts with label limited. Show all posts
Friday, March 30, 2012
Restored SQL 6.5 but can only access locally - Need Help
Pardon my long windedness, but I want to provide a full explanation.
I have very limited (next to none) knowledge of SQL Server or NT / 2000
Server.
We had a membership database stored on an SQL Server 6.5 on an NT system.
We accessed it via a custom written Visual Basic program called Member. The
computer crashed, not the drive. Apparently, it was an old single processor
PC. I tried to move the drive into a newer computer and got a HAL.DLL
error. I was able to recover the DAT files using the drive as a second dive
on a newer PC.
I put the drive in a newer computer and upgraded it to Windows 2000. Then I
reinstalled SQL Server 6.5. I created the matching database and database
devices. I then copied the old DAT files over and it worked. I was able to
access the old database files. Hooray!
I reinstalled the Member program, and sure enough the connection strings
work and I can access my data again. Another Hooray!
Now my only problem is that I cannot connect to the database from any of the
network computers, only locally. I have read many pages on the internet and
experimented quite a bit, but I still get an ODBC timeout failure every time
I try to connect from one of the other computers on the network.
It appears that my SQL is running and sharing the information, but only
locally. Or there is some other reason that I cannot access it over the
network? Any ideas? I really need to get this up and running again soon.
Thanks for any help.
TedDid you enabled the TCP/IP protocol while installing the SQL Server 6.5? If
not go to SQL 6.5 Setup program
and check if the TCP/IP is selected; else include that and try connecting.
Its been a long time I have worked with
SQL 6.5.
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member.
> The computer crashed, not the drive. Apparently, it was an old single
> processor PC. I tried to move the drive into a newer computer and got a
> HAL.DLL error. I was able to recover the DAT files using the drive as a
> second dive on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then
> I reinstalled SQL Server 6.5. I created the matching database and
> database devices. I then copied the old DAT files over and it worked. I
> was able to access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of
> the network computers, only locally. I have read many pages on the
> internet and experimented quite a bit, but I still get an ODBC timeout
> failure every time I try to connect from one of the other computers on the
> network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>|||Hi Ted
Just wondering if you changed the name of the server, in which case you may
need to change the connection properties for the application.
John
"Ted Hadley" wrote:
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member. The
> computer crashed, not the drive. Apparently, it was an old single processor
> PC. I tried to move the drive into a newer computer and got a HAL.DLL
> error. I was able to recover the DAT files using the drive as a second dive
> on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then I
> reinstalled SQL Server 6.5. I created the matching database and database
> devices. I then copied the old DAT files over and it worked. I was able to
> access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of the
> network computers, only locally. I have read many pages on the internet and
> experimented quite a bit, but I still get an ODBC timeout failure every time
> I try to connect from one of the other computers on the network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>
>|||That was exactly the problem. Thank you Hari. I ran the Setup program,
checked TCP/IP, and restarted SQL. It worked immediately.
You're a lifesaver!
Ted
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
> Did you enabled the TCP/IP protocol while installing the SQL Server 6.5?
> If not go to SQL 6.5 Setup program
> and check if the TCP/IP is selected; else include that and try connecting.
> Its been a long time I have worked with
> SQL 6.5.
> Thanks
> Hari
> SQL Server MVP
>
> "Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
> news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
>> Pardon my long windedness, but I want to provide a full explanation.
>> I have very limited (next to none) knowledge of SQL Server or NT / 2000
>> Server.
>> We had a membership database stored on an SQL Server 6.5 on an NT system.
>> We accessed it via a custom written Visual Basic program called Member.
>> The computer crashed, not the drive. Apparently, it was an old single
>> processor PC. I tried to move the drive into a newer computer and got a
>> HAL.DLL error. I was able to recover the DAT files using the drive as a
>> second dive on a newer PC.
>> I put the drive in a newer computer and upgraded it to Windows 2000.
>> Then I reinstalled SQL Server 6.5. I created the matching database and
>> database devices. I then copied the old DAT files over and it worked. I
>> was able to access the old database files. Hooray!
>> I reinstalled the Member program, and sure enough the connection strings
>> work and I can access my data again. Another Hooray!
>> Now my only problem is that I cannot connect to the database from any of
>> the network computers, only locally. I have read many pages on the
>> internet and experimented quite a bit, but I still get an ODBC timeout
>> failure every time I try to connect from one of the other computers on
>> the network.
>> It appears that my SQL is running and sharing the information, but only
>> locally. Or there is some other reason that I cannot access it over the
>> network? Any ideas? I really need to get this up and running again
>> soon.
>> Thanks for any help.
>> Ted
>|||Thats a good news..
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:6a-dnUP6fbGi53LZnZ2dnUVZ_sydnZ2d@.giganews.com...
> That was exactly the problem. Thank you Hari. I ran the Setup program,
> checked TCP/IP, and restarted SQL. It worked immediately.
> You're a lifesaver!
> Ted
> "Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
> news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
>> Did you enabled the TCP/IP protocol while installing the SQL Server 6.5?
>> If not go to SQL 6.5 Setup program
>> and check if the TCP/IP is selected; else include that and try
>> connecting. Its been a long time I have worked with
>> SQL 6.5.
>> Thanks
>> Hari
>> SQL Server MVP
>>
>> "Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
>> news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
>> Pardon my long windedness, but I want to provide a full explanation.
>> I have very limited (next to none) knowledge of SQL Server or NT / 2000
>> Server.
>> We had a membership database stored on an SQL Server 6.5 on an NT
>> system. We accessed it via a custom written Visual Basic program called
>> Member. The computer crashed, not the drive. Apparently, it was an old
>> single processor PC. I tried to move the drive into a newer computer
>> and got a HAL.DLL error. I was able to recover the DAT files using the
>> drive as a second dive on a newer PC.
>> I put the drive in a newer computer and upgraded it to Windows 2000.
>> Then I reinstalled SQL Server 6.5. I created the matching database and
>> database devices. I then copied the old DAT files over and it worked.
>> I was able to access the old database files. Hooray!
>> I reinstalled the Member program, and sure enough the connection strings
>> work and I can access my data again. Another Hooray!
>> Now my only problem is that I cannot connect to the database from any of
>> the network computers, only locally. I have read many pages on the
>> internet and experimented quite a bit, but I still get an ODBC timeout
>> failure every time I try to connect from one of the other computers on
>> the network.
>> It appears that my SQL is running and sharing the information, but only
>> locally. Or there is some other reason that I cannot access it over the
>> network? Any ideas? I really need to get this up and running again
>> soon.
>> Thanks for any help.
>> Ted
>>
>
I have very limited (next to none) knowledge of SQL Server or NT / 2000
Server.
We had a membership database stored on an SQL Server 6.5 on an NT system.
We accessed it via a custom written Visual Basic program called Member. The
computer crashed, not the drive. Apparently, it was an old single processor
PC. I tried to move the drive into a newer computer and got a HAL.DLL
error. I was able to recover the DAT files using the drive as a second dive
on a newer PC.
I put the drive in a newer computer and upgraded it to Windows 2000. Then I
reinstalled SQL Server 6.5. I created the matching database and database
devices. I then copied the old DAT files over and it worked. I was able to
access the old database files. Hooray!
I reinstalled the Member program, and sure enough the connection strings
work and I can access my data again. Another Hooray!
Now my only problem is that I cannot connect to the database from any of the
network computers, only locally. I have read many pages on the internet and
experimented quite a bit, but I still get an ODBC timeout failure every time
I try to connect from one of the other computers on the network.
It appears that my SQL is running and sharing the information, but only
locally. Or there is some other reason that I cannot access it over the
network? Any ideas? I really need to get this up and running again soon.
Thanks for any help.
TedDid you enabled the TCP/IP protocol while installing the SQL Server 6.5? If
not go to SQL 6.5 Setup program
and check if the TCP/IP is selected; else include that and try connecting.
Its been a long time I have worked with
SQL 6.5.
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member.
> The computer crashed, not the drive. Apparently, it was an old single
> processor PC. I tried to move the drive into a newer computer and got a
> HAL.DLL error. I was able to recover the DAT files using the drive as a
> second dive on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then
> I reinstalled SQL Server 6.5. I created the matching database and
> database devices. I then copied the old DAT files over and it worked. I
> was able to access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of
> the network computers, only locally. I have read many pages on the
> internet and experimented quite a bit, but I still get an ODBC timeout
> failure every time I try to connect from one of the other computers on the
> network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>|||Hi Ted
Just wondering if you changed the name of the server, in which case you may
need to change the connection properties for the application.
John
"Ted Hadley" wrote:
> Pardon my long windedness, but I want to provide a full explanation.
> I have very limited (next to none) knowledge of SQL Server or NT / 2000
> Server.
> We had a membership database stored on an SQL Server 6.5 on an NT system.
> We accessed it via a custom written Visual Basic program called Member. The
> computer crashed, not the drive. Apparently, it was an old single processor
> PC. I tried to move the drive into a newer computer and got a HAL.DLL
> error. I was able to recover the DAT files using the drive as a second dive
> on a newer PC.
> I put the drive in a newer computer and upgraded it to Windows 2000. Then I
> reinstalled SQL Server 6.5. I created the matching database and database
> devices. I then copied the old DAT files over and it worked. I was able to
> access the old database files. Hooray!
> I reinstalled the Member program, and sure enough the connection strings
> work and I can access my data again. Another Hooray!
> Now my only problem is that I cannot connect to the database from any of the
> network computers, only locally. I have read many pages on the internet and
> experimented quite a bit, but I still get an ODBC timeout failure every time
> I try to connect from one of the other computers on the network.
> It appears that my SQL is running and sharing the information, but only
> locally. Or there is some other reason that I cannot access it over the
> network? Any ideas? I really need to get this up and running again soon.
> Thanks for any help.
> Ted
>
>|||That was exactly the problem. Thank you Hari. I ran the Setup program,
checked TCP/IP, and restarted SQL. It worked immediately.
You're a lifesaver!
Ted
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
> Did you enabled the TCP/IP protocol while installing the SQL Server 6.5?
> If not go to SQL 6.5 Setup program
> and check if the TCP/IP is selected; else include that and try connecting.
> Its been a long time I have worked with
> SQL 6.5.
> Thanks
> Hari
> SQL Server MVP
>
> "Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
> news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
>> Pardon my long windedness, but I want to provide a full explanation.
>> I have very limited (next to none) knowledge of SQL Server or NT / 2000
>> Server.
>> We had a membership database stored on an SQL Server 6.5 on an NT system.
>> We accessed it via a custom written Visual Basic program called Member.
>> The computer crashed, not the drive. Apparently, it was an old single
>> processor PC. I tried to move the drive into a newer computer and got a
>> HAL.DLL error. I was able to recover the DAT files using the drive as a
>> second dive on a newer PC.
>> I put the drive in a newer computer and upgraded it to Windows 2000.
>> Then I reinstalled SQL Server 6.5. I created the matching database and
>> database devices. I then copied the old DAT files over and it worked. I
>> was able to access the old database files. Hooray!
>> I reinstalled the Member program, and sure enough the connection strings
>> work and I can access my data again. Another Hooray!
>> Now my only problem is that I cannot connect to the database from any of
>> the network computers, only locally. I have read many pages on the
>> internet and experimented quite a bit, but I still get an ODBC timeout
>> failure every time I try to connect from one of the other computers on
>> the network.
>> It appears that my SQL is running and sharing the information, but only
>> locally. Or there is some other reason that I cannot access it over the
>> network? Any ideas? I really need to get this up and running again
>> soon.
>> Thanks for any help.
>> Ted
>|||Thats a good news..
Thanks
Hari
SQL Server MVP
"Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
news:6a-dnUP6fbGi53LZnZ2dnUVZ_sydnZ2d@.giganews.com...
> That was exactly the problem. Thank you Hari. I ran the Setup program,
> checked TCP/IP, and restarted SQL. It worked immediately.
> You're a lifesaver!
> Ted
> "Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
> news:%23Pe%23SG%23xGHA.4576@.TK2MSFTNGP06.phx.gbl...
>> Did you enabled the TCP/IP protocol while installing the SQL Server 6.5?
>> If not go to SQL 6.5 Setup program
>> and check if the TCP/IP is selected; else include that and try
>> connecting. Its been a long time I have worked with
>> SQL 6.5.
>> Thanks
>> Hari
>> SQL Server MVP
>>
>> "Ted Hadley" <thadley@.cypresscoveresort.com> wrote in message
>> news:3MWdnUKfzpi_r3PZnZ2dnUVZ_oCdnZ2d@.giganews.com...
>> Pardon my long windedness, but I want to provide a full explanation.
>> I have very limited (next to none) knowledge of SQL Server or NT / 2000
>> Server.
>> We had a membership database stored on an SQL Server 6.5 on an NT
>> system. We accessed it via a custom written Visual Basic program called
>> Member. The computer crashed, not the drive. Apparently, it was an old
>> single processor PC. I tried to move the drive into a newer computer
>> and got a HAL.DLL error. I was able to recover the DAT files using the
>> drive as a second dive on a newer PC.
>> I put the drive in a newer computer and upgraded it to Windows 2000.
>> Then I reinstalled SQL Server 6.5. I created the matching database and
>> database devices. I then copied the old DAT files over and it worked.
>> I was able to access the old database files. Hooray!
>> I reinstalled the Member program, and sure enough the connection strings
>> work and I can access my data again. Another Hooray!
>> Now my only problem is that I cannot connect to the database from any of
>> the network computers, only locally. I have read many pages on the
>> internet and experimented quite a bit, but I still get an ODBC timeout
>> failure every time I try to connect from one of the other computers on
>> the network.
>> It appears that my SQL is running and sharing the information, but only
>> locally. Or there is some other reason that I cannot access it over the
>> network? Any ideas? I really need to get this up and running again
>> soon.
>> Thanks for any help.
>> Ted
>>
>
Restore without big transaction log
All,
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way to
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.
> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for each file as the one you
were restoring from.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.
|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (existing) destination
database. Won't help, since SQL Server need to create each file with same size as the originating
database has.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegr oups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>
|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This won't help. I assume you mean shrink the transaction log file for the (existing) destination
> database. Won't help, since SQL Server need to create each file with same size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegr oups.com...
>
>
>
>
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way to
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.
> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for each file as the one you
were restoring from.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.
|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (existing) destination
database. Won't help, since SQL Server need to create each file with same size as the originating
database has.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegr oups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>
|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This won't help. I assume you mean shrink the transaction log file for the (existing) destination
> database. Won't help, since SQL Server need to create each file with same size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegr oups.com...
>
>
>
>
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Restore without big transaction log
All,
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way t
o
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for ea
ch file as the one you
were restoring from.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind o
f
> a pain to go through all those steps. I was wondering if anyone knew a way
to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind o
f
> a pain to go through all those steps. I was wondering if anyone knew a way
to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (
existing) destination
database. Won't help, since SQL Server need to create each file with same si
ze as the originating
database has.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This won't help. I assume you mean shrink the transaction log file for the
(existing) destination
> database. Won't help, since SQL Server need to create each file with same
size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph
ttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
>
>
>
>
>
>
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way t
o
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for ea
ch file as the one you
were restoring from.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind o
f
> a pain to go through all those steps. I was wondering if anyone knew a way
to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind o
f
> a pain to go through all those steps. I was wondering if anyone knew a way
to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (
existing) destination
database. Won't help, since SQL Server need to create each file with same si
ze as the originating
database has.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> This won't help. I assume you mean shrink the transaction log file for the
(existing) destination
> database. Won't help, since SQL Server need to create each file with same
size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph
ttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
>
>
>
>
>
>
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Restore without big transaction log
All,
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way to
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for each file as the one you
were restoring from.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (existing) destination
database. Won't help, since SQL Server need to create each file with same size as the originating
database has.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
>> All,
>> Our production database is growing quite rapidly and I'm having trouble
>> refreshing our QA and Dev environments due to limited disk space on those
>> servers. My process now is
>> - Restore the production DB with a new name
>> - Set to simple and shrink the log file to 0
>> - Back up the shrunk db to a new .bak file
>> - Restore to dev or QA from that .bak file
>> Our production DB is way to busy to shrink the log file on and it's kind of
>> a pain to go through all those steps. I was wondering if anyone knew a way to
>> restore from a backup with an empty .trn file? I don't see that this is
>> possible, but thought I'd ask.
>> Thanks in advance.
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> > One solution might be once you backup your production database (full
> > backup) to truncate your transaction log and shrink it, then perform
> > the restore after that.
> This won't help. I assume you mean shrink the transaction log file for the (existing) destination
> database. Won't help, since SQL Server need to create each file with same size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
>
> > On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> > wrote:
> >> All,
> >> Our production database is growing quite rapidly and I'm having trouble
> >> refreshing our QA and Dev environments due to limited disk space on those
> >> servers. My process now is
> >> - Restore the production DB with a new name
> >> - Set to simple and shrink the log file to 0
> >> - Back up the shrunk db to a new .bak file
> >> - Restore to dev or QA from that .bak file
> >> Our production DB is way to busy to shrink the log file on and it's kind of
> >> a pain to go through all those steps. I was wondering if anyone knew a way to
> >> restore from a backup with an empty .trn file? I don't see that this is
> >> possible, but thought I'd ask.
> >> Thanks in advance.
> > One solution might be once you backup your production database (full
> > backup) to truncate your transaction log and shrink it, then perform
> > the restore after that. I would think that would clear up quite a few
> > space issues.- Hide quoted text -
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Our production database is growing quite rapidly and I'm having trouble
refreshing our QA and Dev environments due to limited disk space on those
servers. My process now is
- Restore the production DB with a new name
- Set to simple and shrink the log file to 0
- Back up the shrunk db to a new .bak file
- Restore to dev or QA from that .bak file
Our production DB is way to busy to shrink the log file on and it's kind of
a pain to go through all those steps. I was wondering if anyone knew a way to
restore from a backup with an empty .trn file? I don't see that this is
possible, but thought I'd ask.
Thanks in advance.> I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
Your assumption is correct. A restored database need as big file size for each file as the one you
were restoring from.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"sqlboy2000" <sqlboy2000@.discussions.microsoft.com> wrote in message
news:3357D5E4-5001-42C7-8ED5-E854B7E90711@.microsoft.com...
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.|||On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
wrote:
> All,
> Our production database is growing quite rapidly and I'm having trouble
> refreshing our QA and Dev environments due to limited disk space on those
> servers. My process now is
> - Restore the production DB with a new name
> - Set to simple and shrink the log file to 0
> - Back up the shrunk db to a new .bak file
> - Restore to dev or QA from that .bak file
> Our production DB is way to busy to shrink the log file on and it's kind of
> a pain to go through all those steps. I was wondering if anyone knew a way to
> restore from a backup with an empty .trn file? I don't see that this is
> possible, but thought I'd ask.
> Thanks in advance.
One solution might be once you backup your production database (full
backup) to truncate your transaction log and shrink it, then perform
the restore after that. I would think that would clear up quite a few
space issues.|||> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that.
This won't help. I assume you mean shrink the transaction log file for the (existing) destination
database. Won't help, since SQL Server need to create each file with same size as the originating
database has.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"acorcoran" <acorcoran@.gmail.com> wrote in message
news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
> On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> wrote:
>> All,
>> Our production database is growing quite rapidly and I'm having trouble
>> refreshing our QA and Dev environments due to limited disk space on those
>> servers. My process now is
>> - Restore the production DB with a new name
>> - Set to simple and shrink the log file to 0
>> - Back up the shrunk db to a new .bak file
>> - Restore to dev or QA from that .bak file
>> Our production DB is way to busy to shrink the log file on and it's kind of
>> a pain to go through all those steps. I was wondering if anyone knew a way to
>> restore from a backup with an empty .trn file? I don't see that this is
>> possible, but thought I'd ask.
>> Thanks in advance.
> One solution might be once you backup your production database (full
> backup) to truncate your transaction log and shrink it, then perform
> the restore after that. I would think that would clear up quite a few
> space issues.
>|||On Jul 12, 2:58 am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> > One solution might be once you backup your production database (full
> > backup) to truncate your transaction log and shrink it, then perform
> > the restore after that.
> This won't help. I assume you mean shrink the transaction log file for the (existing) destination
> database. Won't help, since SQL Server need to create each file with same size as the originating
> database has.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "acorcoran" <acorco...@.gmail.com> wrote in message
> news:1184209592.791721.108060@.k79g2000hse.googlegroups.com...
>
> > On Jul 10, 2:20 pm, sqlboy2000 <sqlboy2...@.discussions.microsoft.com>
> > wrote:
> >> All,
> >> Our production database is growing quite rapidly and I'm having trouble
> >> refreshing our QA and Dev environments due to limited disk space on those
> >> servers. My process now is
> >> - Restore the production DB with a new name
> >> - Set to simple and shrink the log file to 0
> >> - Back up the shrunk db to a new .bak file
> >> - Restore to dev or QA from that .bak file
> >> Our production DB is way to busy to shrink the log file on and it's kind of
> >> a pain to go through all those steps. I was wondering if anyone knew a way to
> >> restore from a backup with an empty .trn file? I don't see that this is
> >> possible, but thought I'd ask.
> >> Thanks in advance.
> > One solution might be once you backup your production database (full
> > backup) to truncate your transaction log and shrink it, then perform
> > the restore after that. I would think that would clear up quite a few
> > space issues.- Hide quoted text -
> - Show quoted text -
This is true, however, I guess I was thinking of backing up the
production database, truncting the log file, then re-backing up the
database (just for day 1). When you restore, you will be restoring a
very limited size log file. Of course, I guess this simply depends on
how large your log file grows between your full backups. As all
future backups would consist of a full backup then a truncation,
maintaining the size on your source database.
Just a though.
Subscribe to:
Posts (Atom)