best solutions : sql server replication (Maintenance)

we are frequently running the maintenance tasks on production during that
databases are not accessible.
to avoid this we want to switch over to the standby server during maintenace
and after maintenance has been completed
switch back to primary server.During maintenance all data changes need to be
replicated back to production server.
To accomplish this I am planning to setup database replication from
producation database server to Standby server.
Please advise best solutions for this like microsoft trnsaction
replication,Goldengate replication, wansync replication.
I think microsoft trnsaction replication,Goldengate replication doesn't
support complex shema changes to get replicated.
Requirement :
1. 10 databases need to get replicated (with 30GB - 70GB each)
2. these 10 databases will have schema changes monthly.
3. data changes need to moved from standby to production server after
maintenance has been completed.
Please advise
ThanksI don't think that replication in the answer to your challenge.
What you probably want is a hot standby. Replication is not recommended
since you will have frequently schema changes.
I think you should investigate these solutions:
- (Transaction) Log shipping
- Cross linked San solution
- Clustering
Michel Gosen (MCDBA)
"DKRReddy" <dkrreddy@.hotmail.com> wrote in message
news:evVYWZJMHHA.3312@.TK2MSFTNGP03.phx.gbl...
> we are frequently running the maintenance tasks on production during that
> databases are not accessible.
> to avoid this we want to switch over to the standby server during
> maintenace and after maintenance has been completed
> switch back to primary server.During maintenance all data changes need to
> be replicated back to production server.
> To accomplish this I am planning to setup database replication from
> producation database server to Standby server.
> Please advise best solutions for this like microsoft trnsaction
> replication,Goldengate replication, wansync replication.
> I think microsoft trnsaction replication,Goldengate replication doesn't
> support complex shema changes to get replicated.
> Requirement :
> 1. 10 databases need to get replicated (with 30GB - 70GB each)
> 2. these 10 databases will have schema changes monthly.
> 3. data changes need to moved from standby to production server after
> maintenance has been completed.
> Please advise
> Thanks
>|||Use bi-directional transactional replication for this. You will need to stop
the distribution agents while running your optimizations.
--
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
"DKRReddy" <dkrreddy@.hotmail.com> wrote in message
news:evVYWZJMHHA.3312@.TK2MSFTNGP03.phx.gbl...
> we are frequently running the maintenance tasks on production during that
> databases are not accessible.
> to avoid this we want to switch over to the standby server during
> maintenace and after maintenance has been completed
> switch back to primary server.During maintenance all data changes need to
> be replicated back to production server.
> To accomplish this I am planning to setup database replication from
> producation database server to Standby server.
> Please advise best solutions for this like microsoft trnsaction
> replication,Goldengate replication, wansync replication.
> I think microsoft trnsaction replication,Goldengate replication doesn't
> support complex shema changes to get replicated.
> Requirement :
> 1. 10 databases need to get replicated (with 30GB - 70GB each)
> 2. these 10 databases will have schema changes monthly.
> 3. data changes need to moved from standby to production server after
> maintenance has been completed.
> Please advise
> Thanks
>|||DKRReddy wrote:
> we are frequently running the maintenance tasks on production during that
> databases are not accessible.
> to avoid this we want to switch over to the standby server during maintenace
> and after maintenance has been completed
> switch back to primary server.During maintenance all data changes need to be
> replicated back to production server.
> To accomplish this I am planning to setup database replication from
> producation database server to Standby server.
> Please advise best solutions for this like microsoft trnsaction
> replication,Goldengate replication, wansync replication.
> I think microsoft trnsaction replication,Goldengate replication doesn't
> support complex shema changes to get replicated.
> Requirement :
> 1. 10 databases need to get replicated (with 30GB - 70GB each)
> 2. these 10 databases will have schema changes monthly.
> 3. data changes need to moved from standby to production server after
> maintenance has been completed.
> Please advise
> Thanks
>
What sort of maintenance tasks are you performing?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"DKRReddy" <dkrreddy@.hotmail.com> wrote in message
news:evVYWZJMHHA.3312@.TK2MSFTNGP03.phx.gbl...
> we are frequently running the maintenance tasks on production during that
> databases are not accessible.
> to avoid this we want to switch over to the standby server during
> maintenace and after maintenance has been completed
> switch back to primary server.During maintenance all data changes need to
> be replicated back to production server.
First I would want to know why your databases aren't available during the
maintenance periods.
Almost all maintenance steps can be done with the databases on-line.
> To accomplish this I am planning to setup database replication from
> producation database server to Standby server.
> Please advise best solutions for this like microsoft trnsaction
> replication,Goldengate replication, wansync replication.
> I think microsoft trnsaction replication,Goldengate replication doesn't
> support complex shema changes to get replicated.
> Requirement :
> 1. 10 databases need to get replicated (with 30GB - 70GB each)
> 2. these 10 databases will have schema changes monthly.
> 3. data changes need to moved from standby to production server after
> maintenance has been completed.
> Please advise
> Thanks
>|||During reindex, tables will be locked exclusively.This is main concern.
We have very huge tables , reindex will take hours.
SQL Server version is SQL Server 2000 SP4 on Windows 2003.
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:uF8o$RTMHHA.536@.TK2MSFTNGP02.phx.gbl...
> "DKRReddy" <dkrreddy@.hotmail.com> wrote in message
> news:evVYWZJMHHA.3312@.TK2MSFTNGP03.phx.gbl...
>> we are frequently running the maintenance tasks on production during that
>> databases are not accessible.
>> to avoid this we want to switch over to the standby server during
>> maintenace and after maintenance has been completed
>> switch back to primary server.During maintenance all data changes need to
>> be replicated back to production server.
> First I would want to know why your databases aren't available during the
> maintenance periods.
> Almost all maintenance steps can be done with the databases on-line.
>
>> To accomplish this I am planning to setup database replication from
>> producation database server to Standby server.
>> Please advise best solutions for this like microsoft trnsaction
>> replication,Goldengate replication, wansync replication.
>> I think microsoft trnsaction replication,Goldengate replication doesn't
>> support complex shema changes to get replicated.
>> Requirement :
>> 1. 10 databases need to get replicated (with 30GB - 70GB each)
>> 2. these 10 databases will have schema changes monthly.
>> 3. data changes need to moved from standby to production server after
>> maintenance has been completed.
>> Please advise
>> Thanks
>|||"DKRReddy" <dkrreddy@.hotmail.com> wrote in message
news:edrmFpaMHHA.5064@.TK2MSFTNGP04.phx.gbl...
> During reindex, tables will be locked exclusively.This is main concern.
> We have very huge tables , reindex will take hours.
> SQL Server version is SQL Server 2000 SP4 on Windows 2003.
>
Hmm, have you tried using DBCC INDEXDEFRAG. I find for most cases this is
more than suffecient and it's an online operation which means you can avoid
the whole switchover, etc.|||DKRReddy wrote:
> During reindex, tables will be locked exclusively.This is main concern.
> We have very huge tables , reindex will take hours.
> SQL Server version is SQL Server 2000 SP4 on Windows 2003.
>
Are you just blindly rebuilding all indexes, or are you analyzing them
first to determine which ones actually "need" to be rebuilt? Rebuilding
an index that is minimally fragmented gains you nothing. You should be
checking the degree of fragmentation of each index, and rebuilding only
those that need it. Here's a script to get you started:
http://realsqlguy.com/serendipity/archives/12-Humpty-Dumpty-Sat-On-A-Wall...html
Tracy McKibben
MCDBA
http://www.realsqlguy.com

Best schema for replicate a DB without replicate Data

Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these databases
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breaking
points.
Thanks
HuiSeems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/info_generate_script.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able to
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remove
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also know
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/info_generate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> > Hi,
> >
> > We had log shipping from LA to New York for our mission critical databases.
> > However, the log shipping breaks all the time because some of these databases
> > or tran logs are huge.
> >
> > Afer re-evaluation we found that some DBs we don't really need the data
> > replicated but we do need to keep the schema and objects up to date:
> > everything except the huge volume of data. It does not need to be real time,
> > we could do this once a day.
> > Could someone suggests us what are the better options of doing this? Some
> > way that is simple without a lot of maintenance issues and potential breaking
> > points.
> >
> > Thanks
> >
> > Hui
> >
> >
> >
> >
>
>sql

Best schema for replicate a DB without replicate Data

Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these databases
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breaking
points.
Thanks
Hui
Seems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/inf...ate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:

> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able to
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remove
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also know
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:

> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/inf...ate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>

Best schema for replicate a DB without replicate Data

Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these database
s
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breakin
g
points.
Thanks
HuiSeems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/in...rate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:

> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able t
o
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remov
e
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also kno
w
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:

> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/in...rate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>

Best program for SQL database manipulation

Hello All

I am a relative beginner to SQL databases & new to this forum, so please bear with me if my query is too basic and advise if this question belongs somewhere else

I began working at a company that uses a program that stores data in an SQL database running off a Firebird engine

The program itself doesnt come with database management/administration module, so I'll need to use an external program for manipulating data in the tables that the database contains.

I have relatively little knowledge in SQL programming, which is why I would like to know which is the most powerful program for SQL database updating / manipulation?

This database has tables that has an infinite number of joins with other tables - Even MS Access wasnt able to open a few tables in this database because of the number of joins. I have tried Access & Lotus Approach, Approach manages to do a better job than Access, it open the tables & seems like it will let me import external data directly into the SQL table, but takes forever & usually just bums out giving an error after a very long wait..

My question is - Apart from Access & Approach, are there any more powerful, yet user friendly programs out there that can help me update data directly into SQL tables? What options do I have - the tasks I need to perform are pretty simple updating & cleaning of data already in there

Please, I will hugely appreciate any pointers that you guys the experts might have for me in this regard

Thanks
AlexTry Microsoft SQL Server 2005 Express. It's Free & Downloadable From http://msdn.microsoft.com/vstudio/express/sql/sql

Best Practices Question: Create many common databases or many tables in one data

General Best Practices Question: Create many common data databases or many tables in one database? I am not a DBA!

In developing a web portal, ERP, or any large enterprise wide application made up of smaller task specific applications under the parent environment.

Should the design be to create a common data database and a specific database for each app or just put create one database and use best practices naming conventions? RI may or may not be a concern.

Areas of concern are: Maintenence, Security/Access, Performance, backup/restore, and file system and DB fragmentation benefits/hits.It depends on a whole host of questions. Will you need to do reporting across these applications? How will security need to be handled? What is the estimated size and growth of these seperate applicaitons?|||Originally posted by rhigdon
It depends on a whole host of questions. Will you need to do reporting across these applications? How will security need to be handled? What is the estimated size and growth of these seperate applicaitons?

I know my question is a broad one and it does bring up a whole host of questions. I can see many pros and cons for both approaches.

Reporting would be needed across all dbs or tables.
Security would be ADSI/NT Auth Mode.
Much of the apps data would grow very large (heavy I/O) and independently, while others would grow at a slower rate.|||What do you mean by "many common databases"? Do you mean duplicate schemas? I'd advise against that, unless you want rolling out upgrades, synchronizing lookup tables, and consolidating data for reporting to be a full-time job.

"Put all your eggs in one basket - and then WATCH THAT BASKET!"
-Mark Twain

blindman|||Originally posted by blindman
What do you mean by "many common databases"? Do you mean duplicate schemas? I'd advise against that, unless you want rolling out upgrades, synchronizing lookup tables, and consolidating data for reporting to be a full-time job.

"Put all your eggs in one basket - and then WATCH THAT BASKET!"
-Mark Twain

blindman

Databases that contain the data that is common to a specific application only and each then of those databases containing links to a database that contains data that is shared or common to all other apps/databases.|||If they are truly separate applications, then they should be separate databases.

Roll their data into a central data warehouse for analytical processing.

Maintain common data in central database and publish it to the clients to keep them synchronized. Each application should be stand-alone, and not rely on links to other databases if it can be helped.

This is going to be an ambitious project.

blindman

Best practices for copying databases...

I have two SQL 2K servers, one production and one test. I'd like to know
what the best process is for copying multiple databases from the production
server to the test server.
Put the destination database in bulk logged recovery model for one.
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
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.
|||Hello,
Backup the database in local machine
If the file is really huge then zip the file (This reduces network traffic
and copy the files in network)
Copy the zip file to destination server
Unzip the file and and Restore the database
Thanks
Hari
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.
|||Online? Offline?
Offline:
Detach Database(s) In Question,
Copy The Files Over,
Attach Database on both servers.
Online:
Hari Prasad Suggestion.
Or
Use Copy Database Wizard, I haven't used these in 2000, in 2005 they have
the SSIS packages that work great ;-).
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005
"Fuel451" wrote:

> I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the production
> server to the test server.
|||"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.
It depends.
We have very high-speed networking between our prod and test servers, so I
usually create an empty test database with the right name and restore the
test test from any convenient backup on the production system directly from
the backup file via the admin share for the disk device. On the test server
a command like:
restore database <database> from
disk='\\<prod_server>\<drive>$\mssql\backups\<data base_most_recent_backup>.bak'
with stats=2
usually works like a champ. Your filegroup names might have to be
compatible (we use the defaults). You might have to do user fixups on the
test database - you can build a script for that and execute it after the
restore is complete.
Posted via a free Usenet account from http://www.teranews.com

Best practices for copying databases...

I have two SQL 2K servers, one production and one test. I'd like to know
what the best process is for copying multiple databases from the production
server to the test server.Put the destination database in bulk logged recovery model for one.
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
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.|||Hello,
Backup the database in local machine
If the file is really huge then zip the file (This reduces network traffic
and copy the files in network)
Copy the zip file to destination server
Unzip the file and and Restore the database
Thanks
Hari
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.|||Online? Offline?
Offline:
Detach Database(s) In Question,
Copy The Files Over,
Attach Database on both servers.
Online:
Hari Prasad Suggestion.
Or
Use Copy Database Wizard, I haven't used these in 2000, in 2005 they have
the SSIS packages that work great ;-).
--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005
"Fuel451" wrote:

> I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the productio
n
> server to the test server.|||"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.
It depends.
We have very high-speed networking between our prod and test servers, so I
usually create an empty test database with the right name and restore the
test test from any convenient backup on the production system directly from
the backup file via the admin share for the disk device. On the test server
a command like:
restore database <database> from
disk='\\<prod_server>\<drive>$\mssql\backups\<database_most_recent_backup>.b
ak'
with stats=2
usually works like a champ. Your filegroup names might have to be
compatible (we use the defaults). You might have to do user fixups on the
test database - you can build a script for that and execute it after the
restore is complete.
Posted via a free Usenet account from http://www.teranews.com

Best practices for copying databases...

I have two SQL 2K servers, one production and one test. I'd like to know
what the best process is for copying multiple databases from the production
server to the test server.Put the destination database in bulk logged recovery model for one.
--
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
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.|||Hello,
Backup the database in local machine
If the file is really huge then zip the file (This reduces network traffic
and copy the files in network)
Copy the zip file to destination server
Unzip the file and and Restore the database
Thanks
Hari
"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.|||Online? Offline?
Offline:
Detach Database(s) In Question,
Copy The Files Over,
Attach Database on both servers.
Online:
Hari Prasad Suggestion.
Or
Use Copy Database Wizard, I haven't used these in 2000, in 2005 they have
the SSIS packages that work great ;-).
--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005
"Fuel451" wrote:
> I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the production
> server to the test server.|||"Fuel451" <Fuel451@.discussions.microsoft.com> wrote in message
news:E6241041-7CF4-4C9C-A6C6-93491836F047@.microsoft.com...
>I have two SQL 2K servers, one production and one test. I'd like to know
> what the best process is for copying multiple databases from the
> production
> server to the test server.
It depends.
We have very high-speed networking between our prod and test servers, so I
usually create an empty test database with the right name and restore the
test test from any convenient backup on the production system directly from
the backup file via the admin share for the disk device. On the test server
a command like:
restore database <database> from
disk='\\<prod_server>\<drive>$\mssql\backups\<database_most_recent_backup>.bak'
with stats=2
usually works like a champ. Your filegroup names might have to be
compatible (we use the defaults). You might have to do user fixups on the
test database - you can build a script for that and execute it after the
restore is complete.
Posted via a free Usenet account from http://www.teranews.comsql

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 practices for backup and restore of large replicated databases

Hello,
I am working on a project where we have a large database that is replicated.
My task is to create a backup/restore plan for this project.
I know the basics for backup/restore, but are looking for best practices and
experiences from you who have done this already on a large scale.
Both publisher and subscribers are allowed to do updates. Restore time at
subscribers have to be short and therefore I am looking for a solution where
both publisher and subscribers are backup up.
Thanks in advance for any pointers to white papers, books, emails, etc.
Best regards,
Vemund
Hi Vemund,
Thanks for your post and I would like to take ownership of this thread and
help you with this issue.
Based on my scope, I understood that you would like to find the best
practise about large scale replicated database backup and restore strategy.
Have I understood you? Correct me if I was wrong.
First of all, please understood that it is hard to say what is the best
practice for your porject as I am not sure how much important is the data
for you and how much data lose could be acceptable. You should discussed
this with your users and find the best strategy for your project.
Generally speaking, here are some general recommendations on database
disaster recovery strategy:
1. Make regular backups that reflect your backup strategy. Ask yourselves
the question - how much data can I afford to lose? (1 min, 1 hour, 1 day
worth). Then ensure that the frequency of the backups reflects the answer
to that question.
2. Make backup to a different media from where the database file reside.
That way you protect against a central point of failure. You can consider
backing up to tape or to another disk (share). Consider moving the backed
up data off-site to another location to protect against disasters like
fires, floods, hurricanes, tornadoes, etc.
3. Test your backups on a regular basis by ensuring they are restore-able
on another system. Then run DBCC CHECKDB on those to ensure the original
database or the backup are not damaged.
4. Keep in mind that the data stored in your database(s) may be one of the
most valuable assets your organization has!
In addition, please review the following information in SQL Books On-Line
"Designing a Backup and Restore Strategy"
Here are some precautions a database administrator should take to ensure
the safety of the data:
1. It is always a good idea to ensure that your backup strategy is
sufficient to recover from a catastrophic failure. Offsite storage and
other precautions are appropriate.
2. Test the database restore operation in a secondary or test database on a
frequent basis.
3. Ensure that any caching devices can handle all failure situations (power
outage, bad sectors, bad drives, system outage, lockups, power spike, and
so forth).
4. Ensure that your caching device:
-- Has integrated battery backup.
-- Can reissue writes on power up.
-- Can be fully disabled if necessary.
-- Handles bad sector re-mapping realtime.
5. Enable torn page detection; it has little performance impact.
6. Configure RAID drives allowing for a hot swap of a bad disk drive, if
possible.
7. Use newer caching controllers that allow addition of more disk space
without
restarting the OS. This can be an ideal solution.
Check the following which covers some of this in detail:
SQL Server capacity and storage guide:
http://www.microsoft.com/technet/pro...n/sqlops6.mspx
Windows backup guide:
http://www.microsoft.com/technet/pro...aintain/backup
rest/br04.mspx
Moreover, here is one more WebCast for you, which will discuss Microsoft
SQL Server database files, the different kinds of database backup options
that are available in SQL Server 2000, and some of the factors to consider
when you design a backup strategy. It will talk about best practices for
backing up and restoring database files. It will review some case studies
and talk about how to troubleshoot problems with backup and restore
operations.
Support WebCast: Microsoft SQL Server 2000: Understanding Backup and Restore
http://support.microsoft.com/?id=329833
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Hi Vemund,
I am just checking on your progress regarding the information that was sent
you! I wonder whether my suggestion is useful or you would like to receive
more information on this.
If you encounter any difficulty, please do not hesitate to let me know.
Please post here and let me know the status of your issue. Looking forward
to hearing from you soon
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
sql

Best Practices Database Owner, Database Connection Method (asp)

Hi-

I have a sql server database, and am wring web apps to access it.

I've created databases different ways, and ended up with different owners (eg dbo, nt authority\network services...)

I also have connection strings using windows authentication, and some using a user name and password.

I have read that using windows authentication is the best way to go, as far as security goes, but I have noticed some connectivity issues when I upload the site to the server, and test it remotely.

What is the safest 'owner' of the database, and what's the safest way to connect?

Thanks

Dan

You may get somewhat different details from different people but I think most will agree with what I'm about to say (I may live to regret those words!). Remember that the goal is give your users a little privileges as possible

owner of the database should be dbo

|||

Create a login which has an entry in your Active Directory (AD)*, and give it the needed permissions.

Map that login to a database user (name it MyAppUser), this user has only needed permisions on the database (e.g. execute stored procedures and maybe SELECTing some fields from some tables).

Use Windows Authentication if it is possible.

Encrypt your ConnectionString in your Web.Config file.

*: you can enforce some policies like password has to be strong and changed every two weeks or months. Old password can not be used and some policies that can increase the security.

Remember: Too much security doesn't always good.

Good luck.

|||

One more thing I would like to mention is try to use stored procedures ONLY as much as you can.

This will increase the performance (usually) and make your App secure (e.g. SQL Injuction).

Try to not thatMyAppUserother thatEXECstored procedures.

Insred of sending a lot of T-SQL statments over the network, you will just send the stored procedure name.. and once it is executed it will be cached (better performance for later execution).

Make you logic in the stored procedure, allow you to change the logic later -if needed- without redeploying the application or compiling it.

Good luck.

|||

OK, so stored procedures seems to be a common theme.

hodw do I best use them(SP), and use the GUI advantage of visual studio.net?

Do I write, say a SP called "SP_Update_Client()" Then have the asp.net page call

"SP_Update_Client("Param1","Param2")

and how do I get a hold of the stored procedure IN Visual studio?

thanks

dan

(Im getting lazzy in this GUI world)

|||

You don't "get hold" of a proc like you would, say, a dll. You create a sql command and attach parameters to it as in this example http://www.codeproject.com/useritems/simplecodeasp.asp

Note esp their use of output parameters to return data

|||

hummm-

I think Im starting to get it.

If I am writing a small app (500 users, connecting 10 - 25 x a week) will I notice a benifit of procs? in speed? Or is it more of a security issue at this size?

Thanks so much for the discussion an the artilce

|||

Harperator:

If I am writing a small app (500 users, connecting 10 - 25 x a week) will I notice a benifit of procs? in speed? Or is it more of a security issue at this size?

Stored Procedure = Both security + performance, but the main thing here is the security especially SQL Injuction.

Good luck.

|||

Agree with CS4Ever's statement

Best Practices - Naming conventions

I work with a group of developers that insist their application's success depends on being able to create databases and tables on the fly. Their proposed naming convention is databases (job number) and for tables (job number "_" order number. I tried to explain this plan eludes any "normal" notion of database sanctity or sanity and giving out DDL Admin rights to a .Net component is a bad idea, all to no avail. Anyone out there with an opinion either way or am I taking my title (DBA) too seriously?To create databases and tables on the fly !!!!

Good idea! But who will be in charge for supporting this?
DBA or Developer? I guess anyone knows answer. On fly it is possible to create 'temporary' permanent objects - and remove them by using some rules. Use script for creating DB from application.|||It sounds to me like your developers don't understand the concept of scalability, or they wouldn't need to be creating database on the fly for different job numbers, or different tables for different orders. It sounds absurd, and rather amateur to me (you asked for opinions, right?).

Another 1 or 2 dimensions in their tables would handle it.

blindman|||Sounds like you just caught the SharePoint Team Services bug. Microsoft brags about a server with over 1,000 databases on it. Just tell the developers (and management) that you can not really be responsible for the performance on this machine, since you can not predict disk usage, or reallocate any files anywhere about, because they just keep coming back. If you have one disk fill up, then all you will get is errors from your application. God help you, if you catch a runaway transaction that blows your transaction logs beyond the bounds of normal space, too.

Just remember, just because Microsoft tells you you can do something, doesn't mean you should do it.|||Sound like MCrowley already "been there, done that" like I am in deep
caca with Sharepoint right now. They created DB "on the fly" like rabbit running high on Viagra... The DATA & LOG files default setup in the SQL Server's Properties won't apply to these Sharepoint DB creation (only effective when using GUI to create DB) . The only concept of scalability they can understand is getting higher & higher... :-)|||Sounds to me that your developers just re-invented the concept of partioned tables; however, not really clever. Temporary databases should not the way to do it! Could you get some more deeper into details of your developer's intentions? I'm sure we all here can propose much more cleverer ways to achieve the same.

Best Practice Question

I have around 10 databases currently residing on different platforms which make-up for roughly a terrabyte of information. I would like to migrate all of these DBs over so that they are all managed under one instance of SQL server 2K. In my view this streamlines things a lot and reduces costs of licensing/hardware.

However, is managing all of these databases on one clustered instance of SQL 2k the best approach from a performace stand point? Would it be better to seperate each database onto its own machine? I am under the impression that given enough hardware (processors, RAM) using just one instance of SQL 2k enterprise should be enough to perform the mangement of this data. Is this correct? Is there an optimal model?

Money is always a concern but in this case, performance is the main objective. The size of the data managed will be growing significantly so the system should be scalable.

My background is as a developer so I may not have provided enough to give a good answer. Please ask questions if you need more detail. I am looking for suggestions on the best way to handle this.

Specifically I would like to know the preferred architecture as well as any suggested hardware.

Thanks in advanceThis link may help - http://www.sql-server-performance.com/vldb.asp
I would definitely consider getting some "expert" advice.|||Thanks, Bruce|||Management and administration don't get any better if all databases reside on the same server vs. separate servers. In fact I'd say you may introduce a "one point of failure" situation, especially if you have some ill-tuned or heavily abused databses.

Best Practice for Statistical Data Organization in databases

I'm completely new to databases. What is the best practice for organizing
statistical data in a database? I have 400+ parameters for 185 countries for
20+ years each. How many tables should I use and how should they be
structured (e.g. countries in rows, years in columns, etc).
Thanks!On 26.12.2006 22:04, Beth wrote:
> I'm completely new to databases. What is the best practice for organizing
> statistical data in a database? I have 400+ parameters for 185 countries f
or
> 20+ years each. How many tables should I use and how should they be
> structured (e.g. countries in rows, years in columns, etc).
Difficult to tell without more detail. With what you disclosed I'd
create a single table with columns (country, year, parm1, parm2, ...
parm400). Reason: I assume all these parameters are different values.
With this layout you can easily do calculations for one parameter
through several years etc.
If the number of parameters changes and they all have the same type
(numeric) then you could also do (country, year, parameter_name,
parameter_value). This design is discouraged, there are recent threads
about this concept (called "entity attribute value"), one of them is here:
http://groups.google.com/group/micr...414fe0399e3540f
Kind regards
robert

Best practice for shrinking Databases

Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
Dan
In general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:

>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan
|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com... [vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:

>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan

Best practice for shrinking Databases

Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:

>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages t
o
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.
4ax.com...[vbcol=seagreen]
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:

>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan

Best practice for shrinking Databases

Is there a "best practice" for shrinking databases?
Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
the beginning before shrinking?
I already have Maintenance Plans to backup logs and the database etc. but
wondered about automating the shrink process as well. There seems to be
alot of free space 67%+ in the database and logfile.
DanIn general you want to avoide shrinking databases on a regular basis.
If the database grows back every week, or month, then it obviously
needs the space, so leave the space there! It is a terrible
performance hit to wait while SQL Server allocates more space, you
really don't want it happening more than it must.
So shrinking should be on an as-needed basis.
As for how much elbow room to leave, one rule of thumb I have used is
at least 25% more free space than the largest table. That allows room
for rebuilding a clustered index.
Another rule of thumb is that DBA time costs a lot more than disk
space; managing a database server without plenty of extra disk space
will cost far more dollars in administration than it saves on
hardware.
Roy
On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>Is there a "best practice" for shrinking databases?
>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages to
>the beginning before shrinking?
>I already have Maintenance Plans to backup logs and the database etc. but
>wondered about automating the shrink process as well. There seems to be
>alot of free space 67%+ in the database and logfile.
>Dan|||That's good advice Roy.
When I do shrink it, should I use the option to move the pages to the
beginning before shrinking?
Dan
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:234qv1h601176jknofkr8furr4lr7gc1o1@.4ax.com...
> In general you want to avoide shrinking databases on a regular basis.
> If the database grows back every week, or month, then it obviously
> needs the space, so leave the space there! It is a terrible
> performance hit to wait while SQL Server allocates more space, you
> really don't want it happening more than it must.
> So shrinking should be on an as-needed basis.
> As for how much elbow room to leave, one rule of thumb I have used is
> at least 25% more free space than the largest table. That allows room
> for rebuilding a clustered index.
> Another rule of thumb is that DBA time costs a lot more than disk
> space; managing a database server without plenty of extra disk space
> will cost far more dollars in administration than it saves on
> hardware.
> Roy
>
> On Wed, 22 Feb 2006 17:25:11 -0500, "Dan" <someone@.yahoo.com> wrote:
>>Is there a "best practice" for shrinking databases?
>>Daily, Weekly, Monthly? Daily do a normal 25% free and weekly Move pages
>>to
>>the beginning before shrinking?
>>I already have Maintenance Plans to backup logs and the database etc. but
>>wondered about automating the shrink process as well. There seems to be
>>alot of free space 67%+ in the database and logfile.
>>Dan|||Moving the pages is the only way you will be able to shrink to the
leve you want.
Roy
On Wed, 22 Feb 2006 20:48:23 -0500, "Dan" <someone@.yahoo.com> wrote:
>That's good advice Roy.
>When I do shrink it, should I use the option to move the pages to the
>beginning before shrinking?
>Dan

Best practice for dbo

When setting up databases for end users, what's the best practice regarding who's the dbo for each individual database - the user itself or a sysadmin?
Does it really have any importance at all who the owner (as defined by 'dbo') is ?I'd strongly recommend leaving sa as dbo, and if need be then making the user a member of the db_owner role if you need that.

-PatP|||Thanks.

The issue was raised when I noticed that for older user databases, someone had assigned a system admin as the dbo by his own, personal user name. When than person then left, and his user was removed, those user databases became orphans.|||You can assign db_ddladmin.

db_ddladmin act same as dbo but it has limited rights comparing db_owner.|||I suspect that Coolberg's problem wasn't one of permission level (they want the user to be equivalent to dbo), but one of ownership (they don't want the login to "own" the database).

There are two issues here that are tightly intertwined, and often confused.

A login is what gives a person access to SQL Server. Logins exist at the server level, and can be either SQL Authenticated or Windows Authenticated. Logins are what "own" a database.

A User is what gives a person permissions inside a SQL Server database. Users exist only inside a database, and are logically tied to exactly one login on the server.

I think that Coolberg wants to keep the ownership of the database limited to an administrative login. I strongly recommend using sa (because you just about can't delete that login), but I agree with the general idea regardless of what login you use.

By using this strategy, you can keep the database ownership limited to an administrative login, but still make any database users memebers of the db_owner role (giving them exactly the same permissions as dbo).

-PatP|||Thanks.
Yes, I'll go for the sa user.
My main goal is to avoid getting orphanized databases when users are leaving in the future.

best practice for copying between 2000 and 2005

currently built a new server with sql server 2005,
whats the best practise for copying the databases from a sql 2000 machine ?
backup / restore ? - i tried the copy wizard and it kept falling overNot sure if it is best practice. But I have been using Backup/Restore to
upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
fine.
Linchi
"luna" <luna@.themoon.com> wrote in message
news:p4sGf.16419$Fy4.3228@.newsfe4-win.ntli.net...
> currently built a new server with sql server 2005,
> whats the best practise for copying the databases from a sql 2000 machine
> ?
> backup / restore ? - i tried the copy wizard and it kept falling over
>|||"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:evdU6HSLGHA.984@.tk2msftngp13.phx.gbl...
> Not sure if it is best practice. But I have been using Backup/Restore to
> upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
> fine.
> Linchi
>
great i'll try that today!
mark