log shipping without backing up and restoring the whole database

Hi,
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is that
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore database
in standby mode on the standby server. The only way to do database restore in
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
ThanksEven if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option of
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is that
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore database
> in standby mode on the standby server. The only way to do database restore in
> our case is to use BCV software (disk subsystem on both servers is EMC), and
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardless
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thanks|||Transaction log backups are OK for this scenario. I would be able to backup
transaction log i.e. every 2 hours, copy tl backup to the new sever, and
restore it there. It is full database backup that I cannot apply in this
scenario, because it would take too long. So if I could set secondary
database which is restored using BCV (not native backup), to standby mode,
I'd be able to apply log shipping scenario.
Even LiteSpeed wouldn't help. This database doesn't have much text fields,
so I don't think that compression would be that good. Even if I'd get 50%
compression in database backup file and time needed to restore, it is still
500GB... BTW, BCV restore of 1TB database takes 2-3 hours. Using litespeed,
it would take hours to backup, hours to copy, and hours to restore...
"ChrisR" wrote:
> Even if you could put it into Standby mode, you wouldnt be able to apply
> additional changes without TLog backups. I dont know if there is an option of
> new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
> "Pedja" wrote:
> > Hi,
> > We have specific problem here. We have very large database (1TB) on one
> > server, and we need to set up log shipping to another server. Problem is that
> > we don't make regular sql server backups on the source server because of
> > obvious reason (it would take too long). Therefore we cannot restore database
> > in standby mode on the standby server. The only way to do database restore in
> > our case is to use BCV software (disk subsystem on both servers is EMC), and
> > that software doesn't have option od leaving database in standby mode. My
> > question is "is there any way to put database into standby mode, regardless
> > that is hasn't been restored using sql server native restore procedure?".
> > Servers are sql server 2000, service pack 3.
> > Thanks|||We have a large database that we ship from a remote location as well. What I
did in this was to take a back up(Lite Speed) restore on stand by one time,
then continue with the logs. You do not have to do a full restore daily. When
you restore your transaction logs could you restore on stand by. (We use Lite
Speed Tranasction log as well). What we do is take a nightly backup, and copy
it over so that we have full back up for an emergency, but we never restore
them. It is harmless that backup takes long(you can schedule it for night
time). I have not noticed and significant performance trouble due to back up
in production.
> Transaction log backups are OK for this scenario. I would be able to backup
> transaction log i.e. every 2 hours, copy tl backup to the new sever, and
> restore it there. It is full database backup that I cannot apply in this
> scenario, because it would take too long. So if I could set secondary
> database which is restored using BCV (not native backup), to standby mode,
> I'd be able to apply log shipping scenario.
> Even LiteSpeed wouldn't help. This database doesn't have much text fields,
> so I don't think that compression would be that good. Even if I'd get 50%
> compression in database backup file and time needed to restore, it is still
> 500GB... BTW, BCV restore of 1TB database takes 2-3 hours. Using litespeed,
> it would take hours to backup, hours to copy, and hours to restore...
> "ChrisR" wrote:
> > Even if you could put it into Standby mode, you wouldnt be able to apply
> > additional changes without TLog backups. I dont know if there is an option of
> > new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
> >
> > "Pedja" wrote:
> >
> > > Hi,
> > > We have specific problem here. We have very large database (1TB) on one
> > > server, and we need to set up log shipping to another server. Problem is that
> > > we don't make regular sql server backups on the source server because of
> > > obvious reason (it would take too long). Therefore we cannot restore database
> > > in standby mode on the standby server. The only way to do database restore in
> > > our case is to use BCV software (disk subsystem on both servers is EMC), and
> > > that software doesn't have option od leaving database in standby mode. My
> > > question is "is there any way to put database into standby mode, regardless
> > > that is hasn't been restored using sql server native restore procedure?".
> > > Servers are sql server 2000, service pack 3.
> > > Thanks