Disconnected replication

This is the scenario.
We have one or more laptops that might never be connected to a network. We want to be able to save the data from the server to a USB drive, take the USB drive to a laptop and import the data. We also need to be able to send the data from the laptop to the server the same way (using USB drives) since the data on the laptop have been update/changed or deleted.

Is this even possible, and how do we do it using replication (if possible)?
If it si not possible, what other options do we have?

GeorgeUsually replication works between servers. In you case try to use DTS.|||Originally posted by snail
Usually replication works between servers. In you case try to use DTS.
Would DTS be able to Merge the data between the 2 servers? If so, how do I do it?|||Originally posted by gehrlekrona
Would DTS be able to Merge the data between the 2 servers? If so, how do I do it?

You cold import (export) data from USB drive and merge data by using special stored procedure - it depens on logic of moving your data.

disconnect the user

I'm trying to detach my database.But i couldn't do that coz there are some users connected to it. So how can i disconnect them?is there any way to disconnect them from the DB?
Thanks.In SQL server 2000

When you detach a database it should give you an option to kill all user processes, if you click that it will log off all users.

If not I have some t-sql code that does it.|||It worked fine.Thank you very much.

Disaster recovery planning question

I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
data and logs are on RAID arrays in the storage array. The servers only have
access to its own SQL disks/data through SSP but this could be turned off if
necessary.
My mgr wants me to come up with a disaster recovery solution where - if one
server fails - then "the remaining SQL server can access the access the
databases that reside on the shared array" and those databases would continue
to be live/available. The mgr believes "there should be a way using named SQL
instances and DNS aliases (or local hosts files on the servers) for this to
be possible".
To me it seems like he is looking for cluster functionality without a
cluster and I can't get my mind around his proposed solution.
Does anyone see a way to provide the functionality the mgr is seeking?
Thanks"pdx" <pdx@.discussions.microsoft.com> wrote in message
news:17E5CAFA-B1E0-4468-8CB8-7D320A46407C@.microsoft.com...
>I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP
>MSA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only
> have
> access to its own SQL disks/data through SSP but this could be turned off
> if
> necessary.
> My mgr wants me to come up with a disaster recovery solution where - if
> one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would
> continue
> to be live/available. The mgr believes "there should be a way using named
> SQL
> instances and DNS aliases (or local hosts files on the servers) for this
> to
> be possible".
If he wants automatic yeah, you probably need clustering, or really good
scripting.
BUT, what you can do manually is simply "remap" those LUNS from Server A to
Server B.
Then attach the databases.
HOWEVER, there's some caveats. If Server A fails, the databases may not be
attachable because they weren't shutdown cleanly. But, it MIGHT work.. in
which case your recovery time is minutes, not longer (however long a RESTORE
from backup would take.)
As for Instances/DNS aliases.. possible. Different ways of doing that.
Note with multiple instances, you may hit licensing issues.
So in sum, with some planning it's certainly possible.
I've done this in non-disaster circumstances (i.e. clean database shutdown,
etc.)
> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
> I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only have
> access to its own SQL disks/data through SSP but this could be turned off if
> necessary.
> My mgr wants me to come up with adisaster recoverysolution where - if one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would continue
> to be live/available. The mgr believes "there should be a way using named SQL
> instances and DNS aliases (or local hosts files on the servers) for this to
> be possible".
> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
This is definately a cluster issue as without some kind of IO fencing,
both servers can not access the shared LUN at the same time. MSCS
would do the trick here, however, since you are running SQL 2000
Standard Edition, there is no support for clustering. You can solve
this problem via a third party clustering solution, such as the one
from SteelEye Technology (my employer) called LifeKeeper Protection
Suite for Exchange. Using LifeKeeper, the way we would configure your
solution is to install a second instance of SQL on each of the servers
which would be the backup for the other server's active instance.
LifeKeeper works with either shared storage (as in your case) or
replicated storage, so your current hardware would be sufficient.
Here is a link with some more information.
http://www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||On Apr 12, 1:56 pm, "daveberm" <david.berming...@.steeleye.com> wrote:
> On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
>
>
> > I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
> > 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> > data and logs are on RAID arrays in the storage array. The servers only have
> > access to its own SQL disks/data through SSP but this could be turned off if
> > necessary.
> > My mgr wants me to come up with adisaster recoverysolution where - if one
> > server fails - then "the remaining SQL server can access the access the
> > databases that reside on the shared array" and those databases would continue
> > to be live/available. The mgr believes "there should be a way using named SQL
> > instances and DNS aliases (or local hosts files on the servers) for this to
> > be possible".
> > To me it seems like he is looking for cluster functionality without a
> > cluster and I can't get my mind around his proposed solution.
> > Does anyone see a way to provide the functionality the mgr is seeking?
> > Thanks
> This is definately a cluster issue as without some kind of IO fencing,
> both servers can not access the shared LUN at the same time. MSCS
> would do the trick here, however, since you are running SQL 2000
> Standard Edition, there is no support for clustering. You can solve
> this problem via a third party clustering solution, such as the one
> fromSteelEyeTechnology (my employer) calledLifeKeeperProtection
> Suite for Exchange. UsingLifeKeeper, the way we would configure your
> solution is to install a second instance of SQL on each of the servers
> which would be the backup for the other server's active instance.LifeKeeperworks with either shared storage (as in your case) or
> replicated storage, so your current hardware would be sufficient.
> Here is a link with some more information.
> http://www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
> David A. Bermingham, MCSE, MCSA:Messaging
> Director of Product Managementwww.steeleye.com- Hide quoted text -
> - Show quoted text -
Sorry, LifeKeeper for SQL (not Exchange) is the product you need.

Disaster recovery planning question

I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
data and logs are on RAID arrays in the storage array. The servers only have
access to its own SQL disks/data through SSP but this could be turned off if
necessary.
My mgr wants me to come up with a disaster recovery solution where - if one
server fails - then "the remaining SQL server can access the access the
databases that reside on the shared array" and those databases would continue
to be live/available. The mgr believes "there should be a way using named SQL
instances and DNS aliases (or local hosts files on the servers) for this to
be possible".
To me it seems like he is looking for cluster functionality without a
cluster and I can't get my mind around his proposed solution.
Does anyone see a way to provide the functionality the mgr is seeking?
Thanks
"pdx" <pdx@.discussions.microsoft.com> wrote in message
news:17E5CAFA-B1E0-4468-8CB8-7D320A46407C@.microsoft.com...
>I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP
>MSA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only
> have
> access to its own SQL disks/data through SSP but this could be turned off
> if
> necessary.
> My mgr wants me to come up with a disaster recovery solution where - if
> one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would
> continue
> to be live/available. The mgr believes "there should be a way using named
> SQL
> instances and DNS aliases (or local hosts files on the servers) for this
> to
> be possible".
If he wants automatic yeah, you probably need clustering, or really good
scripting.
BUT, what you can do manually is simply "remap" those LUNS from Server A to
Server B.
Then attach the databases.
HOWEVER, there's some caveats. If Server A fails, the databases may not be
attachable because they weren't shutdown cleanly. But, it MIGHT work.. in
which case your recovery time is minutes, not longer (however long a RESTORE
from backup would take.)
As for Instances/DNS aliases.. possible. Different ways of doing that.
Note with multiple instances, you may hit licensing issues.
So in sum, with some planning it's certainly possible.
I've done this in non-disaster circumstances (i.e. clean database shutdown,
etc.)

> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
> I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only have
> access to its own SQL disks/data through SSP but this could be turned off if
> necessary.
> My mgr wants me to come up with adisaster recoverysolution where - if one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would continue
> to be live/available. The mgr believes "there should be a way using named SQL
> instances and DNS aliases (or local hosts files on the servers) for this to
> be possible".
> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
This is definately a cluster issue as without some kind of IO fencing,
both servers can not access the shared LUN at the same time. MSCS
would do the trick here, however, since you are running SQL 2000
Standard Edition, there is no support for clustering. You can solve
this problem via a third party clustering solution, such as the one
from SteelEye Technology (my employer) called LifeKeeper Protection
Suite for Exchange. Using LifeKeeper, the way we would configure your
solution is to install a second instance of SQL on each of the servers
which would be the backup for the other server's active instance.
LifeKeeper works with either shared storage (as in your case) or
replicated storage, so your current hardware would be sufficient.
Here is a link with some more information.
http://www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||On Apr 12, 1:56 pm, "daveberm" <david.berming...@.steeleye.com> wrote:
> On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
>
>
>
> This is definately a cluster issue as without some kind of IO fencing,
> both servers can not access the shared LUN at the same time. MSCS
> would do the trick here, however, since you are running SQL 2000
> Standard Edition, there is no support for clustering. You can solve
> this problem via a third party clustering solution, such as the one
> fromSteelEyeTechnology (my employer) calledLifeKeeperProtection
> Suite for Exchange. UsingLifeKeeper, the way we would configure your
> solution is to install a second instance of SQL on each of the servers
> which would be the backup for the other server's active instance.LifeKeeperworks with either shared storage (as in your case) or
> replicated storage, so your current hardware would be sufficient.
> Here is a link with some more information.
> http://www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
> David A. Bermingham, MCSE, MCSA:Messaging
> Director of Product Managementwww.steeleye.com- Hide quoted text -
> - Show quoted text -
Sorry, LifeKeeper for SQL (not Exchange) is the product you need.

Disaster recovery planning question

I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP MSA
500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
data and logs are on RAID arrays in the storage array. The servers only have
access to its own SQL disks/data through SSP but this could be turned off if
necessary.
My mgr wants me to come up with a disaster recovery solution where - if one
server fails - then "the remaining SQL server can access the access the
databases that reside on the shared array" and those databases would continu
e
to be live/available. The mgr believes "there should be a way using named SQ
L
instances and DNS aliases (or local hosts files on the servers) for this to
be possible".
To me it seems like he is looking for cluster functionality without a
cluster and I can't get my mind around his proposed solution.
Does anyone see a way to provide the functionality the mgr is seeking?
Thanks"pdx" <pdx@.discussions.microsoft.com> wrote in message
news:17E5CAFA-B1E0-4468-8CB8-7D320A46407C@.microsoft.com...
>I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP
>MSA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only
> have
> access to its own SQL disks/data through SSP but this could be turned off
> if
> necessary.
> My mgr wants me to come up with a disaster recovery solution where - if
> one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would
> continue
> to be live/available. The mgr believes "there should be a way using named
> SQL
> instances and DNS aliases (or local hosts files on the servers) for this
> to
> be possible".
If he wants automatic yeah, you probably need clustering, or really good
scripting.
BUT, what you can do manually is simply "remap" those LUNS from Server A to
Server B.
Then attach the databases.
HOWEVER, there's some caveats. If Server A fails, the databases may not be
attachable because they weren't shutdown cleanly. But, it MIGHT work.. in
which case your recovery time is minutes, not longer (however long a RESTORE
from backup would take.)
As for Instances/DNS aliases.. possible. Different ways of doing that.
Note with multiple instances, you may hit licensing issues.
So in sum, with some planning it's certainly possible.
I've done this in non-disaster circumstances (i.e. clean database shutdown,
etc.)

> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
> I have two SQL 2000 Std servers (running on W2k3 Std) connected to an HP M
SA
> 500 G2 storage array. Each SQL server runs distinct/different DBs. The SQL
> data and logs are on RAID arrays in the storage array. The servers only ha
ve
> access to its own SQL disks/data through SSP but this could be turned off
if
> necessary.
> My mgr wants me to come up with adisaster recoverysolution where - if one
> server fails - then "the remaining SQL server can access the access the
> databases that reside on the shared array" and those databases would conti
nue
> to be live/available. The mgr believes "there should be a way using named
SQL
> instances and DNS aliases (or local hosts files on the servers) for this t
o
> be possible".
> To me it seems like he is looking for cluster functionality without a
> cluster and I can't get my mind around his proposed solution.
> Does anyone see a way to provide the functionality the mgr is seeking?
> Thanks
This is definately a cluster issue as without some kind of IO fencing,
both servers can not access the shared LUN at the same time. MSCS
would do the trick here, however, since you are running SQL 2000
Standard Edition, there is no support for clustering. You can solve
this problem via a third party clustering solution, such as the one
from SteelEye Technology (my employer) called LifeKeeper Protection
Suite for Exchange. Using LifeKeeper, the way we would configure your
solution is to install a second instance of SQL on each of the servers
which would be the backup for the other server's active instance.
LifeKeeper works with either shared storage (as in your case) or
replicated storage, so your current hardware would be sufficient.
Here is a link with some more information.
http://www.steeleye.com/pdf/literat..._sql_server.pdf
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||On Apr 12, 1:56 pm, "daveberm" <david.berming...@.steeleye.com> wrote:
> On Apr 11, 7:42 pm, pdx <p...@.discussions.microsoft.com> wrote:
>
>
>
>
> This is definately a cluster issue as without some kind of IO fencing,
> both servers can not access the shared LUN at the same time. MSCS
> would do the trick here, however, since you are running SQL 2000
> Standard Edition, there is no support for clustering. You can solve
> this problem via a third party clustering solution, such as the one
> fromSteelEyeTechnology (my employer) calledLifeKeeperProtection
> Suite for Exchange. UsingLifeKeeper, the way we would configure your
> solution is to install a second instance of SQL on each of the servers
> which would be the backup for the other server's active instance.LifeKeepe
rworks with either shared storage (as in your case) or
> replicated storage, so your current hardware would be sufficient.
> Here is a link with some more information.
> http://www.steeleye.com/pdf/literat..._sql_server.pdf
> David A. Bermingham, MCSE, MCSA:Messaging
> Director of Product Managementwww.steeleye.com- Hide quoted text -
> - Show quoted text -
Sorry, LifeKeeper for SQL (not Exchange) is the product you need.

Disaster Recovery plan for SQL server

Hi,
We plan to implement Disaster Recovery plan and system
for SQL 2000 server and databases. SQL server is
connected in headquarter network. Recovery SQL server
will stay on remote location (site) and it must have the
most recent copy of SQL production databases.
SQL server has 2 databases. Each database has about 2-3
GB of data. We can expect that database will grow
significantly in the future (10 Gb and more). Databases
accept about 2 MB of data per day. Connection between
headquarter and remote location will probably be on high-
speed WAN (10 Mb/s or more). At any disaster event, we
can loose data for about last 1 hour (maximum 1 hour, not
more anyway)
What is the best solution for implementing Disaster
Recovery?
Backup, restore with STANDBY server on remote location
(with frequently created transaction log backups)?
Or SQL database replication (transaction replication)?
Thanks in advance for help
MilanDefinitely Standby Server with Log Shipping.
Theres lots of info in SQL Books Online and it is offered as a feature with
SQL Enterprise Edition.
--
Regards,
Mandar Naik
This posting is provided AS IS with no warranties, and confers no rights.
"Milan Ojstersek" <milan.ojstersek@.hermes-plus.si> wrote in message
news:087a01c33f07$3e84d700$a301280a@.phx.gbl...
> Hi,
> We plan to implement Disaster Recovery plan and system
> for SQL 2000 server and databases. SQL server is
> connected in headquarter network. Recovery SQL server
> will stay on remote location (site) and it must have the
> most recent copy of SQL production databases.
> SQL server has 2 databases. Each database has about 2-3
> GB of data. We can expect that database will grow
> significantly in the future (10 Gb and more). Databases
> accept about 2 MB of data per day. Connection between
> headquarter and remote location will probably be on high-
> speed WAN (10 Mb/s or more). At any disaster event, we
> can loose data for about last 1 hour (maximum 1 hour, not
> more anyway)
> What is the best solution for implementing Disaster
> Recovery?
> Backup, restore with STANDBY server on remote location
> (with frequently created transaction log backups)?
> Or SQL database replication (transaction replication)?
> Thanks in advance for help
> Milan
>|||I prefer Log Shipping.
"Milan Ojstersek" <milan.ojstersek@.hermes-plus.si> wrote in message
news:087a01c33f07$3e84d700$a301280a@.phx.gbl...
> Hi,
> We plan to implement Disaster Recovery plan and system
> for SQL 2000 server and databases. SQL server is
> connected in headquarter network. Recovery SQL server
> will stay on remote location (site) and it must have the
> most recent copy of SQL production databases.
> SQL server has 2 databases. Each database has about 2-3
> GB of data. We can expect that database will grow
> significantly in the future (10 Gb and more). Databases
> accept about 2 MB of data per day. Connection between
> headquarter and remote location will probably be on high-
> speed WAN (10 Mb/s or more). At any disaster event, we
> can loose data for about last 1 hour (maximum 1 hour, not
> more anyway)
> What is the best solution for implementing Disaster
> Recovery?
> Backup, restore with STANDBY server on remote location
> (with frequently created transaction log backups)?
> Or SQL database replication (transaction replication)?
> Thanks in advance for help
> Milan
>