Best Practices for Moving SQL Server to Another domain?

I've been looking all over the KB trying to find documentation on Best
Practices for moving a SQL Server to another domain. What reACLing needs to
be done to the databases (if any) and what is the best way to do it?
Thanks for any links or help...Here are a couple of Links...
http://support.microsoft.com/default.aspx?scid=kb;en-us;224071
http://support.microsoft.com/default.aspx?scid=kb;en-us;304692
Personally I would go for the first one, as it will transfer everything over.
Once completion do a sp_createstats & sp_updatestats
After than I would advise you run a performance trace for a about a week and
implement any changes, then run the sp_createstats & sp_updatestats again
Peter
"Denial ain't just a river in Egypt."
Mark Twain
"Losferwords" wrote:
> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...|||Let me be a little more specific... I'm moving a SQL Server from DOMAIN A to
DOMAIN B. Any Best Practices Guides on that?
"Losferwords" wrote:
> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...

Best Practices for Moving SQL Server to Another domain?

I've been looking all over the KB trying to find documentation on Best
Practices for moving a SQL Server to another domain. What reACLing needs to
be done to the databases (if any) and what is the best way to do it?
Thanks for any links or help...
Here are a couple of Links...
http://support.microsoft.com/default...b;en-us;224071
http://support.microsoft.com/default...b;en-us;304692
Personally I would go for the first one, as it will transfer everything over.
Once completion do a sp_createstats & sp_updatestats
After than I would advise you run a performance trace for a about a week and
implement any changes, then run the sp_createstats & sp_updatestats again
Peter
"Denial ain't just a river in Egypt."
Mark Twain
"Losferwords" wrote:

> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...
|||Let me be a little more specific... I'm moving a SQL Server from DOMAIN A to
DOMAIN B. Any Best Practices Guides on that?
"Losferwords" wrote:

> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...
sql

Best Practices for Moving SQL Server to Another domain?

I've been looking all over the KB trying to find documentation on Best
Practices for moving a SQL Server to another domain. What reACLing needs to
be done to the databases (if any) and what is the best way to do it?
Thanks for any links or help...Here are a couple of Links...
http://support.microsoft.com/defaul...kb;en-us;224071
http://support.microsoft.com/defaul...kb;en-us;304692
Personally I would go for the first one, as it will transfer everything over
.
Once completion do a sp_createstats & sp_updatestats
After than I would advise you run a performance trace for a about a week and
implement any changes, then run the sp_createstats & sp_updatestats again
Peter
"Denial ain't just a river in Egypt."
Mark Twain
"Losferwords" wrote:

> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs
to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...|||Let me be a little more specific... I'm moving a SQL Server from DOMAIN A t
o
DOMAIN B. Any Best Practices Guides on that?
"Losferwords" wrote:

> I've been looking all over the KB trying to find documentation on Best
> Practices for moving a SQL Server to another domain. What reACLing needs
to
> be done to the databases (if any) and what is the best way to do it?
> Thanks for any links or help...

Best Practices for Changing Merge Replication Server

We are planning on moving some SQL Server databases that are currenlty
running Merge replication as the publisher and distributor. The existing
server will eventually be scrapped and the new server will take over as the
new Publisher/Distributor. The current server is replication to a subscriber
that is also our 24/7 website SQL Server, and cannot be interrupted, and it
is imperative that no transactions on the website server be lost. Can anyone
provide any insight or articles that outline the best approach to take while
doing this migration?
Regards,
With merge replication transactions can be and frequently are rolled back.
So from the start your topology does not make a lot of sense.
If you want to minimize data loss in your situation you would be better off
to make your web server the publisher and configure it with anonymous
subscribers. This way you can drop a subscriber or take it offline and bring
it back on line or redeploy the subscription to a new server with little
impact on the publisher (now the web server). Still you have the possibility
of data loss.
With your current topology there is no way to do this without disruption
your web server/subscriber.
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
"Frank" <Frank@.discussions.microsoft.com> wrote in message
news:075DE1AF-FC0D-4423-8548-E8CCC744558B@.microsoft.com...
> We are planning on moving some SQL Server databases that are currenlty
> running Merge replication as the publisher and distributor. The existing
> server will eventually be scrapped and the new server will take over as
the
> new Publisher/Distributor. The current server is replication to a
subscriber
> that is also our 24/7 website SQL Server, and cannot be interrupted, and
it
> is imperative that no transactions on the website server be lost. Can
anyone
> provide any insight or articles that outline the best approach to take
while
> doing this migration?
> Regards,

Best Oracle source provider?

Hello,
I am using a massive Oracle db in SSIS and am trying to figure out the best way to increase performance in moving data from this db to sql server. As far as Oracle sources, which seem to have the best performance?
Thanks,
AdrianWhat did you mean by the 'Oracle sources'? We tried using OLEDB for oracle and the performance is really poor.|||I've had that experience as well with OLEDB. What I meant by sources is either the .NET OracleClient, Microsoft OLEDB provider for Oracle, or Oracle provider for OLEDB. I believe these are the only 3 options to connect to Oracle. I can't even use the Oracle provider for OLEDB without numerous errors, and have found that the other 2 are quite slow as well. So I was just wondering what other people's experiences were, and if they found 1 to be superior over another. And maybe some input from the SSIS developers as to what their suggestions are.
Thanks,
Adrian|||The OLEDB providers for Oracle that are currently available aren't terribly fast. Have you considered replicating (a subset of) your data to SQL Server from Oracle before (or at the beginning of) your package execution? This topic in BOL is probably where to start: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/rpldata9/html/2e013259-0022-4897-a08d-5f8deb880fa8.htm|||Hello,

We have built a super fast connector for Oracle for SSIS. We have been able to achieve about 30 times performance improvements over the OLEDB Oracle provider. E.g 1 million rows, we loaded in about 2:20 mins. Let me know if you are interested in beta bits.

Regards
Sidharth
http://www.persistentsys.com
siddossy@.hotmail.com

Best Oracle source provider?

Hello,
I am using a massive Oracle db in SSIS and am trying to figure out the best way to increase performance in moving data from this db to sql server. As far as Oracle sources, which seem to have the best performance?
Thanks,
Adrian
What did you mean by the 'Oracle sources'? We tried using OLEDB for oracle and the performance is really poor.|||I've had that experience as well with OLEDB. What I meant by sources is either the .NET OracleClient, Microsoft OLEDB provider for Oracle, or Oracle provider for OLEDB. I believe these are the only 3 options to connect to Oracle. I can't even use the Oracle provider for OLEDB without numerous errors, and have found that the other 2 are quite slow as well. So I was just wondering what other people's experiences were, and if they found 1 to be superior over another. And maybe some input from the SSIS developers as to what their suggestions are.
Thanks,
Adrian
|||The OLEDB providers for Oracle that are currently available aren't terribly fast. Have you considered replicating (a subset of) your data to SQL Server from Oracle before (or at the beginning of) your package execution? This topic in BOL is probably where to start: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/rpldata9/html/2e013259-0022-4897-a08d-5f8deb880fa8.htm|||Hello,

We have built a super fast connector for Oracle for SSIS. We have been able to achieve about 30 times performance improvements over the OLEDB Oracle provider. E.g 1 million rows, we loaded in about 2:20 mins. Let me know if you are interested in beta bits.

Regards
Sidharth
http://www.persistentsys.com
siddossy@.hotmail.com

Benefit of moving Master & TempDB to diff HD

I am interested to hear if people think it would be a good idea to move
the Master & TempDB to a different HD.

Here is my DB Server's set up:
1. Processor: (1) AMD XP 2800
2. 1st HD (IDE 0) is the system & boot drive
3. (3) SCSI HD make up a hardware RAID level 0 (striped without
parity)solution - these striped drives are just for my working DBs
4. (1) SCSI HD that's not doing anything.

I want to put the Master & TempDB on the SCSI HD that's not doing
anything. Would that be the best place for it for maximum performance or
should I put in the striped array. I am leaning more towards putting on
the SCSI HD that's not doing anything. What do you all think?

Ed

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!adude (nospam@.devdex.com) writes:
> I am interested to hear if people think it would be a good idea to move
> the Master & TempDB to a different HD.
> Here is my DB Server's set up:
> 1. Processor: (1) AMD XP 2800
> 2. 1st HD (IDE 0) is the system & boot drive
> 3. (3) SCSI HD make up a hardware RAID level 0 (striped without
> parity)solution - these striped drives are just for my working DBs
> 4. (1) SCSI HD that's not doing anything.
> I want to put the Master & TempDB on the SCSI HD that's not doing
> anything. Would that be the best place for it for maximum performance or
> should I put in the striped array. I am leaning more towards putting on
> the SCSI HD that's not doing anything. What do you all think?

I would not move master.

If that idle HD is on a different controller, moving something could be
good for performance. If you have lots of action in tempdb, this could
be a candidate. You could also consider moving transaction logs to the
idle disc.

If the disk in the same controller as the rest, I think it would be better
to move disk into the stripe. If the IDE disk is slow, you couls still
move tempdn into the RAID.

I need to add the disclaimer that hardware configuration is not my best
game.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

begin transaction in a sp or not

Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
doesn't handle transactions at all. We'll be moving to SQL 2005 soon but don
t
know when. I know I can use Try...Catch in SQL 2005 to do transactions or
actually handle it form the application.
My question is, should I use 'BEGIN TRANSACTION' in a sp or it automatically
runs as a transaction? Thank youIf you want transactional control, then you have to include all data
modification operations inside BEGIN TRAN and COMMIT TRAN. The stored
procedure by itself will not run as a transaction. You have to check for
errors after each data modification operation and decide wheter to continue
or rollback transaction. @.@.TRANCOUNT also comes in handy while handling
transactions. See SQL Server Books Online for more information.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||Try catch has nothing to do with if a transaction is used or not.Whether you
wrap your sp code in a transaction or not depends on what you are doing with
it. If it only does a single insert, update or delete then there is little
point to it. If you modify multiple tables and need them to be
transactionally consistant that is a different story. You might want to have
a looka t this:
http://www.sommarskog.se/error-handling-I.html
Andrew J. Kelly SQL MVP
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||First, TRY...CATCH, in itself, has nothing to do with a TRANSACTION. In SQL
2005, TRY...CATCH allows efficient code management to determine if parts of
the TRANSACTION succeed or fail. And you can use a TRANSACTION in SQL 2000.
You are best served by limiting TRANSACTION to stored procedures ONLY when
transaction control is required for the business needs.
Not every action requires a TRANSACTION. A 'set' of actions (several
INSERT/UPDATE/DELETE statements) that need to be 'all or nothing' should be
explicitly designated to execute in the context of a TRANSACTION.
You may wish to read more about TRANSACTIONs in Books on Line.
Arnie Rowland
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you
Tranactions scoping is part of the busness logic of the applciation, and
should be implemented wherever the business logic lives. Limiting
transactions to inside stored procedures doesn't work if the application
needs to compose multiple stored procedure invocations into a single atomic
business operation.
David|||To add to the other responses, I suggest you specify SET XACT_ABORT ON when
the application is oblivious to explicit transactions in stored procedures.
This will automatically rollback the transaction and abort the batch in most
cases and avoid problems related to an open transaction following a command
timeout.
Hope this helps.
Dan Guzman
SQL Server MVP
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you

begin transaction in a sp or not

Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
doesn't handle transactions at all. We'll be moving to SQL 2005 soon but dont
know when. I know I can use Try...Catch in SQL 2005 to do transactions or
actually handle it form the application.
My question is, should I use 'BEGIN TRANSACTION' in a sp or it automatically
runs as a transaction? Thank youIf you want transactional control, then you have to include all data
modification operations inside BEGIN TRAN and COMMIT TRAN. The stored
procedure by itself will not run as a transaction. You have to check for
errors after each data modification operation and decide wheter to continue
or rollback transaction. @.@.TRANCOUNT also comes in handy while handling
transactions. See SQL Server Books Online for more information.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||Try catch has nothing to do with if a transaction is used or not.Whether you
wrap your sp code in a transaction or not depends on what you are doing with
it. If it only does a single insert, update or delete then there is little
point to it. If you modify multiple tables and need them to be
transactionally consistant that is a different story. You might want to have
a looka t this:
http://www.sommarskog.se/error-handling-I.html
Andrew J. Kelly SQL MVP
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||First, TRY...CATCH, in itself, has nothing to do with a TRANSACTION. In SQL
2005, TRY...CATCH allows efficient code management to determine if parts of
the TRANSACTION succeed or fail. And you can use a TRANSACTION in SQL 2000.
You are best served by limiting TRANSACTION to stored procedures ONLY when
transaction control is required for the business needs.
Not every action requires a TRANSACTION. A 'set' of actions (several
INSERT/UPDATE/DELETE statements) that need to be 'all or nothing' should be
explicitly designated to execute in the context of a TRANSACTION.
You may wish to read more about TRANSACTIONs in Books on Line.
--
Arnie Rowland
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you|||"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you
Tranactions scoping is part of the busness logic of the applciation, and
should be implemented wherever the business logic lives. Limiting
transactions to inside stored procedures doesn't work if the application
needs to compose multiple stored procedure invocations into a single atomic
business operation.
David|||To add to the other responses, I suggest you specify SET XACT_ABORT ON when
the application is oblivious to explicit transactions in stored procedures.
This will automatically rollback the transaction and abort the batch in most
cases and avoid problems related to an open transaction following a command
timeout.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"tpp" <tpp@.discussions.microsoft.com> wrote in message
news:AB989028-45EE-4D6E-A346-C16C08227C31@.microsoft.com...
> Hey. I've SQL 2000 ent. ed. right now. The application is vb .net and it
> doesn't handle transactions at all. We'll be moving to SQL 2005 soon but
> dont
> know when. I know I can use Try...Catch in SQL 2005 to do transactions or
> actually handle it form the application.
> My question is, should I use 'BEGIN TRANSACTION' in a sp or it
> automatically
> runs as a transaction? Thank you