Showing posts with label solution. Show all posts
Showing posts with label solution. Show all posts

Friday, February 24, 2012

Backup/Restore: Restoring to new server without rerunning a snapshot

I am designing a solution that utilizes replication from a front-end database to a back-end database. Historical data will be truncated from the front-end database in such a way that these truncation deletes will not be replicated - thus, the back-end database acts as a historical archive for the front-end database.

I am concerned about backup and restore scenarios for this environment.

Once we have begun truncating data from the front-end database, we will never be able to re-snapshot the database to rebuild the back-end database.

My concern comes if the servers are destroyed and the environment must be rebuilt. For SQL Server 2000, Books Online says:

"When you restore a backup of a replicated database to a server or database other than the one on which it was created, your replication settings cannot be preserved. For publishing databases and merge subscribing databases, a full restore of the database and logs is followed by an automatic removal of replication meta data from the database when the database or server you restore to differs from the one on which the backup was created."

Books Online for SQL Server 2005 has a similar statement. Does this mean that I would be unable to restore my front-end and back-end databases, and reestablish replication without taking a new snapshot? Does SQL 2005 provide any advantages for disaster recovery given this scenario? Does restoring with the KEEP_REPLICATION option override the behavior specified in the above BOL quote?

That isn't correct. You can restore a backup without preserving replication settings and then reconfigure replication in that environment. You would not want to issue a snapshot, so you would simply tell the replication engine that the subscriber already has the schema and data.

Now, there are two different behavior paths. With SQL Server 2000, you would tell it that the subscriber already has the schema and data "nosynch" and a subscription would be created, but changes would fail, because you would have to manually create the replication stored procedures that are called on the subscriber. But, once created, all of the data would flow normally.

With SQL Server 2005, you create the subscription with replication support only. This would not cause a snapshot to be sent to the subscriber, but it would create all of the necessary replication objects.

|||

Hello,

I have read your comments about restoring backup in a diferent server. This is my case and I am really desesperated becuase I am totally unable to do it . I only have a backup from the old server and I have no idea about scripts procedures or programming I am only trying from the SQL SERVER Enterprise Manager. Please let me know if it does really exist the posibility.

Thanks a lot

Carlos

|||did you found any solution for this?

Backup/Restore: Restoring to new server without rerunning a snapshot

I am designing a solution that utilizes replication from a front-end database to a back-end database. Historical data will be truncated from the front-end database in such a way that these truncation deletes will not be replicated - thus, the back-end database acts as a historical archive for the front-end database.

I am concerned about backup and restore scenarios for this environment.

Once we have begun truncating data from the front-end database, we will never be able to re-snapshot the database to rebuild the back-end database.

My concern comes if the servers are destroyed and the environment must be rebuilt. For SQL Server 2000, Books Online says:

"When you restore a backup of a replicated database to a server or database other than the one on which it was created, your replication settings cannot be preserved. For publishing databases and merge subscribing databases, a full restore of the database and logs is followed by an automatic removal of replication meta data from the database when the database or server you restore to differs from the one on which the backup was created."

Books Online for SQL Server 2005 has a similar statement. Does this mean that I would be unable to restore my front-end and back-end databases, and reestablish replication without taking a new snapshot? Does SQL 2005 provide any advantages for disaster recovery given this scenario? Does restoring with the KEEP_REPLICATION option override the behavior specified in the above BOL quote?

That isn't correct. You can restore a backup without preserving replication settings and then reconfigure replication in that environment. You would not want to issue a snapshot, so you would simply tell the replication engine that the subscriber already has the schema and data.

Now, there are two different behavior paths. With SQL Server 2000, you would tell it that the subscriber already has the schema and data "nosynch" and a subscription would be created, but changes would fail, because you would have to manually create the replication stored procedures that are called on the subscriber. But, once created, all of the data would flow normally.

With SQL Server 2005, you create the subscription with replication support only. This would not cause a snapshot to be sent to the subscriber, but it would create all of the necessary replication objects.

|||

Hello,

I have read your comments about restoring backup in a diferent server. This is my case and I am really desesperated becuase I am totally unable to do it . I only have a backup from the old server and I have no idea about scripts procedures or programming I am only trying from the SQL SERVER Enterprise Manager. Please let me know if it does really exist the posibility.

Thanks a lot

Carlos

Thursday, February 16, 2012

Backup/archive - simple question

I am a developer, not a DBA. I have a simple need, and a simple
solution, but I expect my solution is far from as efficient or elegant
as it could be. I would like to archive a group of records from a log
table that I have, and then delete said records from the table. I
would like to write them to a disk file in such a way that they could
be recovered if necessary. I have a simple query to select the
records I'd like to archive that looks something like this:
select * from mylogtable
where ((level = 'Debug') and (timestamp < '9/7/2007'))
or (timestamp < '9/1/2007')
Yes, there are indices on "timestamp" and "level". The dates in the
query should change as I run this job, and I'd probably run it
something like once a week.
I can do this simply by running the query in "SQL Server Management
Studio" and sending the results to a file. Is there a better way?
Ideally I'd like to schedule this task but that's secondary to running
it efficiently.
Thanks!
Brad.You could think using Partitioning in large environments (this is a new
feature of SQL Server 2005 and it only can be used in Enterprise Edition).
http://msdn2.microsoft.com/en-us/library/ms345146.aspx
But for your environment, Files and Filesgroups would be enough I guess?
If you want to learn more about Files and Files Groups, you can visit the
following page:
http://msdn2.microsoft.com/en-us/library/ms189126.aspx
--
Ekrem Önsoy
"Bradley Plett" <plettb@.newsgroup.nospam> wrote in message
news:d69be3l84tlaphq7dljbvfh314u4j8mc06@.4ax.com...
>I am a developer, not a DBA. I have a simple need, and a simple
> solution, but I expect my solution is far from as efficient or elegant
> as it could be. I would like to archive a group of records from a log
> table that I have, and then delete said records from the table. I
> would like to write them to a disk file in such a way that they could
> be recovered if necessary. I have a simple query to select the
> records I'd like to archive that looks something like this:
> select * from mylogtable
> where ((level = 'Debug') and (timestamp < '9/7/2007'))
> or (timestamp < '9/1/2007')
> Yes, there are indices on "timestamp" and "level". The dates in the
> query should change as I run this job, and I'd probably run it
> something like once a week.
> I can do this simply by running the query in "SQL Server Management
> Studio" and sending the results to a file. Is there a better way?
> Ideally I'd like to schedule this task but that's secondary to running
> it efficiently.
> Thanks!
> Brad.|||I'm still no expert, but I think the "bcp" utility is what I was
looking for. :-)
Brad.
On Mon, 10 Sep 2007 14:19:29 -0600, Bradley Plett
<plettb@.newsgroup.nospam> wrote:
>I am a developer, not a DBA. I have a simple need, and a simple
>solution, but I expect my solution is far from as efficient or elegant
>as it could be. I would like to archive a group of records from a log
>table that I have, and then delete said records from the table. I
>would like to write them to a disk file in such a way that they could
>be recovered if necessary. I have a simple query to select the
>records I'd like to archive that looks something like this:
>select * from mylogtable
>where ((level = 'Debug') and (timestamp < '9/7/2007'))
>or (timestamp < '9/1/2007')
>Yes, there are indices on "timestamp" and "level". The dates in the
>query should change as I run this job, and I'd probably run it
>something like once a week.
>I can do this simply by running the query in "SQL Server Management
>Studio" and sending the results to a file. Is there a better way?
>Ideally I'd like to schedule this task but that's secondary to running
>it efficiently.
>Thanks!
>Brad.|||That or use DTS.
"Bradley Plett" <plettb@.newsgroup.nospam> wrote in message
news:8khbe35v1m0rttv6mbre1vuob46fidcblg@.4ax.com...
> I'm still no expert, but I think the "bcp" utility is what I was
> looking for. :-)
> Brad.
> On Mon, 10 Sep 2007 14:19:29 -0600, Bradley Plett
> <plettb@.newsgroup.nospam> wrote:
>>I am a developer, not a DBA. I have a simple need, and a simple
>>solution, but I expect my solution is far from as efficient or elegant
>>as it could be. I would like to archive a group of records from a log
>>table that I have, and then delete said records from the table. I
>>would like to write them to a disk file in such a way that they could
>>be recovered if necessary. I have a simple query to select the
>>records I'd like to archive that looks something like this:
>>select * from mylogtable
>>where ((level = 'Debug') and (timestamp < '9/7/2007'))
>>or (timestamp < '9/1/2007')
>>Yes, there are indices on "timestamp" and "level". The dates in the
>>query should change as I run this job, and I'd probably run it
>>something like once a week.
>>I can do this simply by running the query in "SQL Server Management
>>Studio" and sending the results to a file. Is there a better way?
>>Ideally I'd like to schedule this task but that's secondary to running
>>it efficiently.
>>Thanks!
>>Brad.|||Hi Brad,
Yes, for your requirement, I believe that bcp utility is the most simple
and efficient way. If you have a large amount of data to be transferred, I
recommend that you use this way.
For detail information, you may refer to the segment "F. Copying data from
a query to a data file" from this article:
bcp Utility
http://msdn2.microsoft.com/en-us/library/ms162802.aspx
You may also want the following reference:
Importing and Exporting Bulk Data by Using the bcp Utility
http://technet.microsoft.com/en-us/library/aa337544.aspx
Additionally I would like to introduce a new feature of SQL Server 2005 for
data transfer. You can also use a SSIS package to do this. Please see the
following steps:
1. Open SQL Server Intelligence Development Studio, create a SSIS project;
2. Switch to the Data Flow pane, drag an OLEDB or DataReader source, double
click the source and create an OLEDB (for OLEDB Source) or ADO.NET (for
DataReader source) connection for it;
3. Input T-SQL statement to the SqlCommand field in Component Properties
and click OK.
4. Drag a Flat File Destination to the Data Flow pane, and drag the output
green line of the source to the Flat File Destination;
5. Double click the Flat File Destination, create a Flat File connection
for specifying an empty file and define the text format;
6. Save the package and execute it.
You may want to get familiar with SSIS from the following references:
An Introduction to SQL Server 2005 Integration Services
http://www.microsoft.com/technet/prodtechnol/sql/2005/intro2is.mspx
Managing and Deploying SQL Server Integration Services
http://www.microsoft.com/technet/prodtechnol/sql/2005/mgngssis.mspx
Hope this helps. If you have any other questions or concerns, please feel
free to let us know. Have a great day!
Best regards,
Charles Wang
Microsoft Online Community Support
=====================================================When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================|||I misunderstood your question, sorry.
--
Ekrem Önsoy
"Bradley Plett" <plettb@.newsgroup.nospam> wrote in message
news:8khbe35v1m0rttv6mbre1vuob46fidcblg@.4ax.com...
> I'm still no expert, but I think the "bcp" utility is what I was
> looking for. :-)
> Brad.
> On Mon, 10 Sep 2007 14:19:29 -0600, Bradley Plett
> <plettb@.newsgroup.nospam> wrote:
>>I am a developer, not a DBA. I have a simple need, and a simple
>>solution, but I expect my solution is far from as efficient or elegant
>>as it could be. I would like to archive a group of records from a log
>>table that I have, and then delete said records from the table. I
>>would like to write them to a disk file in such a way that they could
>>be recovered if necessary. I have a simple query to select the
>>records I'd like to archive that looks something like this:
>>select * from mylogtable
>>where ((level = 'Debug') and (timestamp < '9/7/2007'))
>>or (timestamp < '9/1/2007')
>>Yes, there are indices on "timestamp" and "level". The dates in the
>>query should change as I run this job, and I'd probably run it
>>something like once a week.
>>I can do this simply by running the query in "SQL Server Management
>>Studio" and sending the results to a file. Is there a better way?
>>Ideally I'd like to schedule this task but that's secondary to running
>>it efficiently.
>>Thanks!
>>Brad.