Hi,
What's the best way to move a database from development server (once you
have done all the testing and everything runs fine) to the production server
?
Thanks in advance."sharman" <sharman@.discussions.microsoft.com> wrote in message
news:4E363380-ED77-4A23-8F76-6EAB7573394B@.microsoft.com...
> Hi,
> What's the best way to move a database from development server (once you
> have done all the testing and everything runs fine) to the production
> server?
> Thanks in advance.|||"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:4E363380-ED77-4A23-8F76-6EAB7573394B@.microsoft.com...
> Hi,
> What's the best way to move a database from development server (once you
> have done all the testing and everything runs fine) to the production
> server?
> Thanks in advance.|||Hi,
1. Perform a database backup in Dev server
2. Send the BAK file to prod server
3. Restore the database into right drives
4. Clean up all the development data
5. Increase the MDF and LDF size. Project atleast for next 1 year.
6. Setup the recovery model to FULL
7. Setup the FULL Backup and Transaction log backup jobs
8. Setup the DBCC CHECKDB job every day night
9. Setup the Update Statistics every day night
10. Setup the Re-Indexing jobs every weekends...
Thanks
Hari
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:4E363380-ED77-4A23-8F76-6EAB7573394B@.microsoft.com...
> Hi,
> What's the best way to move a database from development server (once you
> have done all the testing and everything runs fine) to the production
> server?
> Thanks in advance.|||Use Backup/Restore. (Leaves a copy for DEV use.)
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:4E363380-ED77-4A23-8F76-6EAB7573394B@.microsoft.com...
> Hi,
> What's the best way to move a database from development server (once you
> have done all the testing and everything runs fine) to the production
> server?
> Thanks in advance.|||Hi
This will depend on what you want to do! If you only have one live site you
may use the backup/restore approach as described by others. If you have
multiple sites or if there is any cleaning up then you may want build basic
database in the development environment and then ship this template database
into live. You could then have an installation process which adds any site
specific data. Whatever method you use it should be tested!
This may be useful http://support.microsoft.com/kb/314546
John
"sharman" wrote:
> Hi,
> What's the best way to move a database from development server (once you
> have done all the testing and everything runs fine) to the production serv
er?
> Thanks in advance.|||Hi,
Thanks for the reply. I was reading the article at
http://support.microsoft.com/kb/314546 and found that it mentions moving the
logins, jobs, alerts, operators and dts packages separately.
I have done backup/restore procedures before and I recall that everything
related to the databse (logins, passwords, dts packages) gets moved except
for the jobs, alerts and operators that has to be set up separately. Please
correct me if I am wrong. Thanks again.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> This will depend on what you want to do! If you only have one live site yo
u
> may use the backup/restore approach as described by others. If you have
> multiple sites or if there is any cleaning up then you may want build basi
c
> database in the development environment and then ship this template databa
se
> into live. You could then have an installation process which adds any site
> specific data. Whatever method you use it should be tested!
> This may be useful http://support.microsoft.com/kb/314546
> John
> "sharman" wrote:
>|||Jobs, Alerts, Operators, DTS Packages, etc., are not database specific, but
server specific,and kept in the msdb database. Anything that is not
accessible throught the user database (using EM or SSMS) is not included in
a database backup. If you want those items, you will need to script them out
and add the scripts to the installation process.
Perhaps you can also move the msdb database. See:
Moving Databases to a new location
http://support.microsoft.com/kb/224071/EN-US/
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:356DBCC1-E61B-478A-82D7-8BC784EC281F@.microsoft.com...[vbcol=seagreen]
> Hi,
> Thanks for the reply. I was reading the article at
> http://support.microsoft.com/kb/314546 and found that it mentions moving
> the
> logins, jobs, alerts, operators and dts packages separately.
> I have done backup/restore procedures before and I recall that everything
> related to the databse (logins, passwords, dts packages) gets moved except
> for the jobs, alerts and operators that has to be set up separately.
> Please
> correct me if I am wrong. Thanks again.
> "John Bell" wrote:
>|||Hi
Your database users will get transferred, but if your destination machine is
not on the same domain or if you are using SQL Server logins, then you will
most likely get orphaned users which are users who are not associated to a
login. See http://support.microsoft.com/kb/274188/ for more on this.
Jobs etc can be scripted (which if you are using source code control you
would have done already!) and recreated on the destination server. For DTS
packages you can use DTS Backup http://www.sqldts.com/default.aspx?242.
HTH
John
"sharman" wrote:
[vbcol=seagreen]
> Hi,
> Thanks for the reply. I was reading the article at
> http://support.microsoft.com/kb/314546 and found that it mentions moving t
he
> logins, jobs, alerts, operators and dts packages separately.
> I have done backup/restore procedures before and I recall that everything
> related to the databse (logins, passwords, dts packages) gets moved except
> for the jobs, alerts and operators that has to be set up separately. Pleas
e
> correct me if I am wrong. Thanks again.
> "John Bell" wrote:
>|||Jobs, Alerts, Operators, DTS Packages, etc., are not database specific, but
server specific,and kept in the msdb database. Anything that is not
accessible throught the user database (using EM or SSMS) is not included in
a database backup. If you want those items, you will need to script them out
and add the scripts to the installation process.
Perhaps you can also move the msdb database. See:
Moving Databases to a new location
http://support.microsoft.com/kb/224071/EN-US/
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:356DBCC1-E61B-478A-82D7-8BC784EC281F@.microsoft.com...[vbcol=seagreen]
> Hi,
> Thanks for the reply. I was reading the article at
> http://support.microsoft.com/kb/314546 and found that it mentions moving
> the
> logins, jobs, alerts, operators and dts packages separately.
> I have done backup/restore procedures before and I recall that everything
> related to the databse (logins, passwords, dts packages) gets moved except
> for the jobs, alerts and operators that has to be set up separately.
> Please
> correct me if I am wrong. Thanks again.
> "John Bell" wrote:
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment