How can we copy a database from one server to a different sever which is having replication.Can anyone help me on this issue.BACKUP and RESTORE?|||How can i stop the rtansactional replication between two databases residing on two different servers. And I want to start the replication after some time.How to achieve this.
Thanks.|||How to take the full backup the database from one server onto a tape and how to restore it onto a different server.
Thanks
Showing posts with label replication. Show all posts
Showing posts with label replication. Show all posts
Sunday, March 11, 2012
Sunday, February 19, 2012
Converting to use replication
I have a DB running under SQL 2005. I would like to enable the database for
replication to offline clients (SQLExpress) and SQL Server 2005 Compact
Edition.
Will converting the primary keys of the database to use GUID's be sufficient
to enable the replication to work property.? They are currently integers.
No, don't do this. Replication will add its own GUID key.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>I have a DB running under SQL 2005. I would like to enable the database
>for
> replication to offline clients (SQLExpress) and SQL Server 2005 Compact
> Edition.
> Will converting the primary keys of the database to use GUID's be
> sufficient
> to enable the replication to work property.? They are currently integers.
|||I know that it does this, but my keys are autonumber fields, so wouldn't it
be better to convert them to GUIDs so that clashes don't occur later on.
Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
will this still occur even when GUIDs are already present?
"Hilary Cotter" wrote:
> No, don't do this. Replication will add its own GUID key.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>
>
|||Either consider automatic identity range management or use different seeds
on either side, i.e. even on one side, odd on another.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...[vbcol=seagreen]
>I know that it does this, but my keys are autonumber fields, so wouldn't it
> be better to convert them to GUIDs so that clashes don't occur later on.
> Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
> will this still occur even when GUIDs are already present?
> "Hilary Cotter" wrote:
|||Might still go with GUIDs - as the number of clients could vary so it will be
easier to manage.
So will using GUIDs stop the extra GUID being added by SQL Server?
"Hilary Cotter" wrote:
> Either consider automatic identity range management or use different seeds
> on either side, i.e. even on one side, odd on another.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...
>
>
|||You can add your own GUID field and call it what you want. Replication
needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
finds an existing one it will use that instead of creating a new one.
Just remember to set the field default to (newid()).
I agree with the advice not to set your primary key to a GUID. You will
run into performance problems when the table grows. Searching an integer
index is much faster than searching an GUID index. Auto identity
requires management, but it is definately the way to go.
Nick Zdunic wrote:[vbcol=seagreen]
> Might still go with GUIDs - as the number of clients could vary so it will be
> easier to manage.
> So will using GUIDs stop the extra GUID being added by SQL Server?
> "Hilary Cotter" wrote:
|||Int's will be faster, but with more than 5 replicas and maybe even 10 to 50
managing autonumber fields would be a nightmare.
"JE" wrote:
> You can add your own GUID field and call it what you want. Replication
> needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
> finds an existing one it will use that instead of creating a new one.
> Just remember to set the field default to (newid()).
> I agree with the advice not to set your primary key to a GUID. You will
> run into performance problems when the table grows. Searching an integer
> index is much faster than searching an GUID index. Auto identity
> requires management, but it is definately the way to go.
>
> Nick Zdunic wrote:
>
replication to offline clients (SQLExpress) and SQL Server 2005 Compact
Edition.
Will converting the primary keys of the database to use GUID's be sufficient
to enable the replication to work property.? They are currently integers.
No, don't do this. Replication will add its own GUID key.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>I have a DB running under SQL 2005. I would like to enable the database
>for
> replication to offline clients (SQLExpress) and SQL Server 2005 Compact
> Edition.
> Will converting the primary keys of the database to use GUID's be
> sufficient
> to enable the replication to work property.? They are currently integers.
|||I know that it does this, but my keys are autonumber fields, so wouldn't it
be better to convert them to GUIDs so that clashes don't occur later on.
Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
will this still occur even when GUIDs are already present?
"Hilary Cotter" wrote:
> No, don't do this. Replication will add its own GUID key.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:A04F975C-AC8F-4FDB-A6D4-030C21392DFF@.microsoft.com...
>
>
|||Either consider automatic identity range management or use different seeds
on either side, i.e. even on one side, odd on another.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...[vbcol=seagreen]
>I know that it does this, but my keys are autonumber fields, so wouldn't it
> be better to convert them to GUIDs so that clashes don't occur later on.
> Because the fields are GUIDs SQL server shouldn't need to add GUIDs - or
> will this still occur even when GUIDs are already present?
> "Hilary Cotter" wrote:
|||Might still go with GUIDs - as the number of clients could vary so it will be
easier to manage.
So will using GUIDs stop the extra GUID being added by SQL Server?
"Hilary Cotter" wrote:
> Either consider automatic identity range management or use different seeds
> on either side, i.e. even on one side, odd on another.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Nick Zdunic" <NickZdunic@.discussions.microsoft.com> wrote in message
> news:EEEEBE0A-22E9-432A-A2AF-98EF18806B7A@.microsoft.com...
>
>
|||You can add your own GUID field and call it what you want. Replication
needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
finds an existing one it will use that instead of creating a new one.
Just remember to set the field default to (newid()).
I agree with the advice not to set your primary key to a GUID. You will
run into performance problems when the table grows. Searching an integer
index is much faster than searching an GUID index. Auto identity
requires management, but it is definately the way to go.
Nick Zdunic wrote:[vbcol=seagreen]
> Might still go with GUIDs - as the number of clients could vary so it will be
> easier to manage.
> So will using GUIDs stop the extra GUID being added by SQL Server?
> "Hilary Cotter" wrote:
|||Int's will be faster, but with more than 5 replicas and maybe even 10 to 50
managing autonumber fields would be a nightmare.
"JE" wrote:
> You can add your own GUID field and call it what you want. Replication
> needs a uniqueidentifier field with the ROWGUIDCOL property set. If it
> finds an existing one it will use that instead of creating a new one.
> Just remember to set the field default to (newid()).
> I agree with the advice not to set your primary key to a GUID. You will
> run into performance problems when the table grows. Searching an integer
> index is much faster than searching an GUID index. Auto identity
> requires management, but it is definately the way to go.
>
> Nick Zdunic wrote:
>
Subscribe to:
Posts (Atom)