Please help compatiblity between VS2003 and SQL server 2005

We have an existing project developed using VS 2003 with SQL server 2000.

Now planning to switch to SQL server 2005.

Are there any compatibility issues between VS 2003 and SQL server 2005, Plus sql server reporting services 2005.

We have been developing this project over a year and don't want to mess it. Now we are at the stage of developing reports and finidng lot of problems with sql server 2000 reporting services.

Thank you very much for the information.

We moved from VS 2003 and Sql Server 2000 to VS 2005 with Sql Server 2005 and only ran into one issue. We had one stored proc that had a Union query. This query worked differently in Sql Server 2005. Everything else was fine - no problem.

Have not worked with reporting services ...

Please help - Named instances and full-text search

I asked this last week and no one replied :-(
i have a sql server 2000 default instance and i'm planning on adding
a sql server 2005 named
instance to the server. both will be using full text search. i
assume that each
instance should be assigned separate directories for their full text
catalog files?
Hi Derek
"Derek" wrote:

> I asked this last week and no one replied :-(
> i have a sql server 2000 default instance and i'm planning on adding
> a sql server 2005 named
> instance to the server. both will be using full text search. i
> assume that each
> instance should be assigned separate directories for their full text
> catalog files?
>
The location for the FTS catalogs can be specified using the ON PATH
parameter of the CREATE FULLTEXT CATALOG command
http://msdn2.microsoft.com/en-gb/library/ms189520.aspx
or by us filling in the Catalog location in the dialog presented on SSMS
http://msdn2.microsoft.com/en-us/library/ms183531.aspx
Each instance has it's own FTS service therefore they can be configured
separately.
http://msdn2.microsoft.com/en-us/library/ms142490.aspx
and (I believe) there is an option to specify the default directory during
setup.
John

Please help - Named instances and full-text search

I asked this last week and no one replied :-(
i have a sql server 2000 default instance and i'm planning on adding
a sql server 2005 named
instance to the server. both will be using full text search. i
assume that each
instance should be assigned separate directories for their full text
catalog files?Hi Derek
"Derek" wrote:

> I asked this last week and no one replied :-(
> i have a sql server 2000 default instance and i'm planning on adding
> a sql server 2005 named
> instance to the server. both will be using full text search. i
> assume that each
> instance should be assigned separate directories for their full text
> catalog files?
>
The location for the FTS catalogs can be specified using the ON PATH
parameter of the CREATE FULLTEXT CATALOG command
http://msdn2.microsoft.com/en-gb/library/ms189520.aspx
or by us filling in the Catalog location in the dialog presented on SSMS
http://msdn2.microsoft.com/en-us/library/ms183531.aspx
Each instance has it's own FTS service therefore they can be configured
separately.
http://msdn2.microsoft.com/en-us/library/ms142490.aspx
and (I believe) there is an option to specify the default directory during
setup.
Johnsql

Please help - Named instances and full-text search

I asked this last week and no one replied :-(
i have a sql server 2000 default instance and i'm planning on adding
a sql server 2005 named
instance to the server. both will be using full text search. i
assume that each
instance should be assigned separate directories for their full text
catalog files?Hi Derek
"Derek" wrote:
> I asked this last week and no one replied :-(
> i have a sql server 2000 default instance and i'm planning on adding
> a sql server 2005 named
> instance to the server. both will be using full text search. i
> assume that each
> instance should be assigned separate directories for their full text
> catalog files?
>
The location for the FTS catalogs can be specified using the ON PATH
parameter of the CREATE FULLTEXT CATALOG command
http://msdn2.microsoft.com/en-gb/library/ms189520.aspx
or by us filling in the Catalog location in the dialog presented on SSMS
http://msdn2.microsoft.com/en-us/library/ms183531.aspx
Each instance has it's own FTS service therefore they can be configured
separately.
http://msdn2.microsoft.com/en-us/library/ms142490.aspx
and (I believe) there is an option to specify the default directory during
setup.
John

Planning the rebuild of a merge publication (publisher) server

I am currently running a SQL Server 2000, which hosts the replication
publisher & distributor of a large merge publication DB. The current NT 4.0
server is scheduled for complete replacement and upgrade (to Win Server 2003
w/ SQL Server 2000) and I am looking for best practice recommendations for
transferring this database and replication topology from one system to
another. If possible, I would prefer to not to have to perform a complete
rebuild the replication topology. SQL BOL seems to indicate that Backup &
Recovery is not an option. Any ideas?
Thanks, Kevin
Kevin,
you should be able to detach and attach your publication database provided
you migrate master, msdb and the distribution database first, and the new
server name is identical to the old one. If this is too much hassle, then
you'd be better off scripting out the replication settings, tailoring them
with the new server name and then recreating from scratch.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Planning replication

Good morning to all ...
This is my scenario:
1. We will have a central publisher
2. We will have SQL Subscribers
3. The data can be changed on the subscriber and in the publisher.
4. The central publisher will have 1 database that acts like a central
repository
for all the other suscription servers.
5. The data changes performed on the central database that belong to a
particular
server only should be replicated to that server.
Can this be done using replication ?
I have been reading about replication and "maybe" merge replication could be
a solution, but I
am not sure if the horizontal filtering will satisfy all my requirements.
Please I need some guidelines to perform this process
Thanks for any contribution,
Raul
Raul,
this can be achieved using merge. You might want to read up on dynamic
filters, as you need to filter the data depending on the subscriber. As well
as the details in BOL, you can use -HOSTNAME in the merge agent's exe
parameters to partition the data.
HTH,
Paul Ibison
|||"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uzqUUNzcEHA.1656@.TK2MSFTNGP09.phx.gbl...
> Raul,
> this can be achieved using merge. You might want to read up on dynamic
> filters, as you need to filter the data depending on the subscriber. As
well
> as the details in BOL, you can use -HOSTNAME in the merge agent's exe
> parameters to partition the data.
> HTH,
> Paul Ibison
>
Thank you for your answer Paul ...
Please help, I have another question, What if a table in my database (The
same on publisher and subscribers) has an identity column defined, and the
same RecordID is replicated to my central server from two different
subscribers ? I have read that assigning a range for the identity fields is
one possible solution however this delimited my solution scalability, There
is another way to take care of this issue ?
Thank you,
Raul
|||Raul,
if the identity column is the PK column, then the values can't be allowed to
overlap but if it is part of a multi-column then matches are not necessarily
a problem. In the first case you can have SQL server assign ranges or
manually manage them yourself. Michael Hotek has outlined a neat algorithm
to ensure no overlaps for several subscribers, using odd and even ranges
with/without negative values etc. Either way is possible for a lot of
subscribers so isn't inherantly unscalable. Another thread today deals with
the pros and cons of guids vs identies, but generally identities are
preferred.
HTH,
Paul Ibison

Planning on going with dynamic SQL, but...

I've read a few posts on the stored procedure vs dynamic sql debate. I ran a few performance test for myself and it appears to be a wash.

Given that, I'm leaning toward dynamic sql mostly because it would mean one fewer place to have things.

But, before we go that route we wanted to ask the question:

Is there any compelling reason why we shouldn't abandon all of our stored procs and just write the SQL inside inside our functions in our business layer (essentially our data access layer)?

Or, is it just preference these days?

I was leaning toward procs, but I have to admit it would be nice not to have to keep up with all of them per all of our functions that call them.

Thanks,
Ron

That is sometimes a 'heated' discussion. How it goes usually depends upon whether the speakers background comes from the development world or the database world.

The Developer wants full and unfettered access to the data in order to easily create an application to solve a problem. The DBA wants to protect the data at all costs.|||

Your tests may indicate a wash but SQL Server cannot cache a query plan for embedded SQL.

It isn't scalable.

Dynamic SQL has god-awful performance issues.

I cannot believe there is even a debate in this forum surrounding embedded SQL. i've read some of the other posts - and i can tell you that the reason DBAs do not like and frequently don't even allow dynamic/embedded SQL is because THEY KNOW MORE ABOUT SQL SERVER than developers. I couldn't write a connection string in C## to save my behind, but I can tell you that you should not under any circumstances use embedded SQL, and I know this from 10+ years of SQL Server experience. I've seen it used to hack. I've seen it bring a server to it's knees.

perhaps the developers who favor embedded or dynamic SQL have never monitored the SQL server during the use of such code. (?)

once you get actual data and multiple users hitting your database, in a real world environment, you WILL NOT see a 'wash' on performance.

The security issues are even worse. No organization that goes through even minimal security audits will allow embedded SQL in an application.

SQL Server may appear to be a fairly user friendly database, and it has a lot of stuff built in that makes it seem as if almost anyone can be a DBA. This is misleading. It is not just another MS Access "database".

If I were you, I would listen to actual DBAs on this issue.

Planning of log backup suggestions

Hello Guys,
I would like to overwrite the log file every two weeks.
The log file is backed up every hours every hours (append to the
device) and the full backup runs every day at 11 pm.
I would like to run a job that overwrite the log backup every two
weeks. What do you advice me to do? at which time is better?
I would like to overwrite the file every two weeks at 10 pm before of
the full backup.
any suggestion?
Ina
ina

> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
BACKUP LOG... WITH INIT just after FULL BACKUP of the database
If you do Database20061101.bak as regular full backup , try to compare
GETDATE() -14 with '20061101' portion of .BAK file
Tools
1)CONVERT function
2)SUBSTRING/RIGHT/LEFT functions
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163408898.605077.87490@.m73g2000cwd.googlegro ups.com...
> Hello Guys,
> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
>
> I would like to run a job that overwrite the log backup every two
> weeks. What do you advice me to do? at which time is better?
> I would like to overwrite the file every two weeks at 10 pm before of
> the full backup.
> any suggestion?
> Ina
>
|||Thanks Uri,
I did not understand the this:
If you do Database20061101.bak as regular full backup , try to compare

> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
Ina
Uri Dimant wrote:
[vbcol=seagreen]
> ina
>
> BACKUP LOG... WITH INIT just after FULL BACKUP of the database
> If you do Database20061101.bak as regular full backup , try to compare
> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163408898.605077.87490@.m73g2000cwd.googlegro ups.com...
|||ina
It is how you identify your backup file
DECLARE @.FileName AS VARCHAR(255)
DECLARE @.Date AS VARCHAR(20)
SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
BACKUP DATABASE dbname TO DISK = @.FileName
Now you have to compare , whether the .BAK file is two weeks old and if it
is you just perform BACKUP LOG ...WITH INIT
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163414330.502761.160300@.h48g2000cwc.googlegr oups.com...
> Thanks Uri,
> I did not understand the this:
> If you do Database20061101.bak as regular full backup , try to compare
>
> Ina
>
> Uri Dimant wrote:
>
|||Ah ok thanks did not know So I can do a job that everyday test this
validation and if it true a overwrite the device.
Ina
Uri Dimant wrote:
[vbcol=seagreen]
> ina
> It is how you identify your backup file
> DECLARE @.FileName AS VARCHAR(255)
> DECLARE @.Date AS VARCHAR(20)
> SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
> SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
> BACKUP DATABASE dbname TO DISK = @.FileName
>
> Now you have to compare , whether the .BAK file is two weeks old and if it
> is you just perform BACKUP LOG ...WITH INIT
>
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163414330.502761.160300@.h48g2000cwc.googlegr oups.com...

Planning of log backup suggestions

Hello Guys,
I would like to overwrite the log file every two weeks.
The log file is backed up every hours every hours (append to the
device) and the full backup runs every day at 11 pm.
I would like to run a job that overwrite the log backup every two
weeks. What do you advice me to do? at which time is better?
I would like to overwrite the file every two weeks at 10 pm before of
the full backup.
any suggestion?
Inaina
> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
BACKUP LOG... WITH INIT just after FULL BACKUP of the database
If you do Database20061101.bak as regular full backup , try to compare
GETDATE() -14 with '20061101' portion of .BAK file
Tools
1)CONVERT function
2)SUBSTRING/RIGHT/LEFT functions
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...
> Hello Guys,
> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
>
> I would like to run a job that overwrite the log backup every two
> weeks. What do you advice me to do? at which time is better?
> I would like to overwrite the file every two weeks at 10 pm before of
> the full backup.
> any suggestion?
> Ina
>|||Thanks Uri,
I did not understand the this:
If you do Database20061101.bak as regular full backup , try to compare
> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
Ina
Uri Dimant wrote:
> ina
> > I would like to overwrite the log file every two weeks.
> >
> > The log file is backed up every hours every hours (append to the
> > device) and the full backup runs every day at 11 pm.
>
> BACKUP LOG... WITH INIT just after FULL BACKUP of the database
> If you do Database20061101.bak as regular full backup , try to compare
> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...
> > Hello Guys,
> >
> > I would like to overwrite the log file every two weeks.
> >
> > The log file is backed up every hours every hours (append to the
> > device) and the full backup runs every day at 11 pm.
> >
> >
> > I would like to run a job that overwrite the log backup every two
> > weeks. What do you advice me to do? at which time is better?
> >
> > I would like to overwrite the file every two weeks at 10 pm before of
> > the full backup.
> >
> > any suggestion?
> >
> > Ina
> >|||ina
It is how you identify your backup file
DECLARE @.FileName AS VARCHAR(255)
DECLARE @.Date AS VARCHAR(20)
SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
BACKUP DATABASE dbname TO DISK = @.FileName
Now you have to compare , whether the .BAK file is two weeks old and if it
is you just perform BACKUP LOG ...WITH INIT
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163414330.502761.160300@.h48g2000cwc.googlegroups.com...
> Thanks Uri,
> I did not understand the this:
> If you do Database20061101.bak as regular full backup , try to compare
>> GETDATE() -14 with '20061101' portion of .BAK file
>> Tools
>> 1)CONVERT function
>> 2)SUBSTRING/RIGHT/LEFT functions
> Ina
>
> Uri Dimant wrote:
>> ina
>> > I would like to overwrite the log file every two weeks.
>> >
>> > The log file is backed up every hours every hours (append to the
>> > device) and the full backup runs every day at 11 pm.
>>
>> BACKUP LOG... WITH INIT just after FULL BACKUP of the database
>> If you do Database20061101.bak as regular full backup , try to compare
>> GETDATE() -14 with '20061101' portion of .BAK file
>> Tools
>> 1)CONVERT function
>> 2)SUBSTRING/RIGHT/LEFT functions
>>
>>
>>
>> "ina" <roberta.inalbon@.gmail.com> wrote in message
>> news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...
>> > Hello Guys,
>> >
>> > I would like to overwrite the log file every two weeks.
>> >
>> > The log file is backed up every hours every hours (append to the
>> > device) and the full backup runs every day at 11 pm.
>> >
>> >
>> > I would like to run a job that overwrite the log backup every two
>> > weeks. What do you advice me to do? at which time is better?
>> >
>> > I would like to overwrite the file every two weeks at 10 pm before of
>> > the full backup.
>> >
>> > any suggestion?
>> >
>> > Ina
>> >
>|||Ah ok thanks did not know So I can do a job that everyday test this
validation and if it true a overwrite the device.
Ina
Uri Dimant wrote:
> ina
> It is how you identify your backup file
> DECLARE @.FileName AS VARCHAR(255)
> DECLARE @.Date AS VARCHAR(20)
> SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
> SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
> BACKUP DATABASE dbname TO DISK = @.FileName
>
> Now you have to compare , whether the .BAK file is two weeks old and if it
> is you just perform BACKUP LOG ...WITH INIT
>
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163414330.502761.160300@.h48g2000cwc.googlegroups.com...
> > Thanks Uri,
> >
> > I did not understand the this:
> >
> > If you do Database20061101.bak as regular full backup , try to compare
> >
> >> GETDATE() -14 with '20061101' portion of .BAK file
> >>
> >> Tools
> >>
> >> 1)CONVERT function
> >> 2)SUBSTRING/RIGHT/LEFT functions
> >
> > Ina
> >
> >
> > Uri Dimant wrote:
> >
> >> ina
> >>
> >> > I would like to overwrite the log file every two weeks.
> >> >
> >> > The log file is backed up every hours every hours (append to the
> >> > device) and the full backup runs every day at 11 pm.
> >>
> >>
> >> BACKUP LOG... WITH INIT just after FULL BACKUP of the database
> >>
> >> If you do Database20061101.bak as regular full backup , try to compare
> >> GETDATE() -14 with '20061101' portion of .BAK file
> >>
> >> Tools
> >>
> >> 1)CONVERT function
> >> 2)SUBSTRING/RIGHT/LEFT functions
> >>
> >>
> >>
> >>
> >>
> >>
> >> "ina" <roberta.inalbon@.gmail.com> wrote in message
> >> news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...
> >> > Hello Guys,
> >> >
> >> > I would like to overwrite the log file every two weeks.
> >> >
> >> > The log file is backed up every hours every hours (append to the
> >> > device) and the full backup runs every day at 11 pm.
> >> >
> >> >
> >> > I would like to run a job that overwrite the log backup every two
> >> > weeks. What do you advice me to do? at which time is better?
> >> >
> >> > I would like to overwrite the file every two weeks at 10 pm before of
> >> > the full backup.
> >> >
> >> > any suggestion?
> >> >
> >> > Ina
> >> >
> >

Planning of log backup suggestions

Hello Guys,
I would like to overwrite the log file every two weeks.
The log file is backed up every hours every hours (append to the
device) and the full backup runs every day at 11 pm.
I would like to run a job that overwrite the log backup every two
weeks. What do you advice me to do? at which time is better?
I would like to overwrite the file every two weeks at 10 pm before of
the full backup.
any suggestion?
Inaina

> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
BACKUP LOG... WITH INIT just after FULL BACKUP of the database
If you do Database20061101.bak as regular full backup , try to compare
GETDATE() -14 with '20061101' portion of .BAK file
Tools
1)CONVERT function
2)SUBSTRING/RIGHT/LEFT functions
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...
> Hello Guys,
> I would like to overwrite the log file every two weeks.
> The log file is backed up every hours every hours (append to the
> device) and the full backup runs every day at 11 pm.
>
> I would like to run a job that overwrite the log backup every two
> weeks. What do you advice me to do? at which time is better?
> I would like to overwrite the file every two weeks at 10 pm before of
> the full backup.
> any suggestion?
> Ina
>|||Thanks Uri,
I did not understand the this:
If you do Database20061101.bak as regular full backup , try to compare

> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
Ina
Uri Dimant wrote:
[vbcol=seagreen]
> ina
>
>
> BACKUP LOG... WITH INIT just after FULL BACKUP of the database
> If you do Database20061101.bak as regular full backup , try to compare
> GETDATE() -14 with '20061101' portion of .BAK file
> Tools
> 1)CONVERT function
> 2)SUBSTRING/RIGHT/LEFT functions
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163408898.605077.87490@.m73g2000cwd.googlegroups.com...|||ina
It is how you identify your backup file
DECLARE @.FileName AS VARCHAR(255)
DECLARE @.Date AS VARCHAR(20)
SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
BACKUP DATABASE dbname TO DISK = @.FileName
Now you have to compare , whether the .BAK file is two weeks old and if it
is you just perform BACKUP LOG ...WITH INIT
"ina" <roberta.inalbon@.gmail.com> wrote in message
news:1163414330.502761.160300@.h48g2000cwc.googlegroups.com...
> Thanks Uri,
> I did not understand the this:
> If you do Database20061101.bak as regular full backup , try to compare
>
> Ina
>
> Uri Dimant wrote:
>
>|||Ah ok thanks did not know So I can do a job that everyday test this
validation and if it true a overwrite the device.
Ina
Uri Dimant wrote:
[vbcol=seagreen]
> ina
> It is how you identify your backup file
> DECLARE @.FileName AS VARCHAR(255)
> DECLARE @.Date AS VARCHAR(20)
> SET @.Date =CONVERT(VARCHAR(10),GETDATE(),112)
> SELECT @.FileName = 'C:\dbname' + @.Date+'.bak'
> BACKUP DATABASE dbname TO DISK = @.FileName
>
> Now you have to compare , whether the .BAK file is two weeks old and if i
t
> is you just perform BACKUP LOG ...WITH INIT
>
>
>
>
> "ina" <roberta.inalbon@.gmail.com> wrote in message
> news:1163414330.502761.160300@.h48g2000cwc.googlegroups.com...

Planning for SQL Server 2005: 64-bit, OS, processor, memory

I was browsing Microsoft's SQL Server site, looking for
some details about SQL Server 2005. Didn't find what
I was looking for...

I'm thinking about moving an existing SQL Server 2000
workload to a new box, using SQL Server 2005, and
maybe the 64-bit version.

My questions are:

1. What is the current target date for release of SQL Server 2005?
Will 64-bit ship when 32-bit ships?

2. Will 64-bit SQL Server 2005 require a special version
of Windows Server 2003 (e.g. Windows Server 2003 Enterprise x64)?
Will it work with both Intel and AMD processors?

3. How many CPUs, and how much memory, will be supported by
SQL Server 2005, 32-bit and 64-bit, on each OS that can run
SQL Server 2005.

I'm looking for a chart here, something like the chart on
page 117 of Kalen Delaney's "Inside SQL Server 2000" book.

SQL Server 2005 SQL Server 2005
Feature Enterprise 32-bit Enterprise 64-bit
------ ------ ------
CPUs supported
Win Srvr 2003:
Win Srvr 2003 Adv:
Win Srvr 2003 Ent x64:

Physical memory
supported
Win Srvr 2003:
Win Srvr 2003 Adv:
Win Srvr 2003 Ent x64:

Has Microsoft published this info, and I just can find it?Larry Bertolini (bertolini.1@.osu.edu) writes:
> I was browsing Microsoft's SQL Server site, looking for
> some details about SQL Server 2005. Didn't find what
> I was looking for...
> I'm thinking about moving an existing SQL Server 2000
> workload to a new box, using SQL Server 2005, and
> maybe the 64-bit version.
> My questions are:
> 1. What is the current target date for release of SQL Server 2005?

The only answer I have heard is "when we're ready". Maybe someone
has said things like "second half of 2005". But I think that is about
as precise information you can get.

> Will 64-bit ship when 32-bit ships?

Since every drop I've seen of SQL2005 has included 64-bit, I see no
reason to assume that 64-bit would not ship when 32-bit ships.

> 2. Will 64-bit SQL Server 2005 require a special version
> of Windows Server 2003 (e.g. Windows Server 2003 Enterprise x64)?

I don't think the whole thing about editions have been sorted out
yet.

> Will it work with both Intel and AMD processors?

Provided that Win2003 SP1 has shipped by then, I would assume so.

> 3. How many CPUs, and how much memory, will be supported by
> SQL Server 2005, 32-bit and 64-bit, on each OS that can run
> SQL Server 2005.

Again, I don't think anything that has been finalized yet. These
limits may not necessarily be hard limits, but rather what sort
of configuration that actually has been tested.

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

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

Planning for Merge - security

Synchronizing passes information (sometimes sensitive) over a wire.
My client, the U.S. Government, will be sync'n over a VPN tunnel to the main
SQL Server database from various field office locations across the country.
My question is: can the sync operation (bulk load/transactions passed) be
encrypted, irrespective of any hardware/network method, by SQL Server during
the process? Any thoughts are appreciated..
Normally when you use a VPN the communication is encrypted enough. For a
greater level of encryption, you can configure your server using Server
Network Utility to force protocol encryption.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"JimMac" <JimMac@.discussions.microsoft.com> wrote in message
news:A201999B-B63B-415B-BA47-B0D1AF1EF622@.microsoft.com...
> Synchronizing passes information (sometimes sensitive) over a wire.
> My client, the U.S. Government, will be sync'n over a VPN tunnel to the
main
> SQL Server database from various field office locations across the
country.
> My question is: can the sync operation (bulk load/transactions passed) be
> encrypted, irrespective of any hardware/network method, by SQL Server
during
> the process? Any thoughts are appreciated..

Planning for Disaster Recovery in second data center..

We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas

"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:

> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi

> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver

Planning for Disaster Recovery in second data center..

We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Fre
e
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Lo
g
> shipping to have the data to the remote site. We are looking at RTO and RP
O
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event o
f
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on
a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SA
N
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:

> Does it impact the primary site while you setup Storage replication? Does
it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live wit
h
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi

> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver

Planning for Disaster Recovery in second data center..

We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas

"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:

> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi

> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver

Planning for Disaster Recovery in second data center..

We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
>> Free !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
>> Log shipping to have the data to the remote site. We are looking at RTO
>> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in
>> the event of a disaster.
>>
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
> Free
>> !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
> Log
>> shipping to have the data to the remote site. We are looking at RTO and
> RPO
>> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> of
>> a disaster.
>>
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> > The main difference between SAN mirroring and Database Mirroring/Log
> > Shipping has to do with which machines are left online at the DR site.
> >
> > By mirroring the SAN, you can mirror the entire Data Center only need to
> > keep the remote SAN turned on, no hosts.
> >
> > In Database Mirroring/Log Shipping, you have to have the remote site fully
> > operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> > etc.
> > And, you have to perform Database Mirroring/Log Shipping on a database per
> > database configuration. If you have an installation with, say, 50 or more
> > databases, it is going to be a real pain attempting to mirror or ship logs
> > for each of them.
> >
> > If you extrapolate this for the entire Data Center, you will see that
> > mirroring the disks to remote hosts is going to be more efficient,
> > administratively at least.
> >
> > Be careful though. SAN mirroring comes in at least 3 flavors:
> > Synchronous,
> > Asynchronous, and Snap Copy. Each has its purpose and potential
> > drawbacks.
> > You need to understand how each works.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > --
> >
> > "Hassan" <hassan@.hotmail.com> wrote in message
> > news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> >> We are planning on using Database Mirroring internally within the data
> >> center for HA and since its used, I am left now with log shipping or
> >> possibly some SAN replication.
> >>
> >> I think either one will work with log shipping being very affordable..
> > Free
> >> !!!
> >>
> >> Does anyone see any pros to SAN replication as the strategy compared to
> > Log
> >> shipping to have the data to the remote site. We are looking at RTO and
> > RPO
> >> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> > of
> >> a disaster.
> >>
> >>
> >>
> >
> >
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
>> Hari,
>> If I use mirroring or Log shipping, why would one consider storage
>> replication like EMCs SRDF ?
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver

Planning execution of package

How can i plan the execution of a package ?

For exemple, i want to execute it every 5 minutes from 8 AM to 20 PM

ThanksSQL Agent provides scheduled execution times etc. you can use to do such things.
Right click on the Agent node in Management Studio, select new job. Select the schedule tab and note that there are ways to schedule a job daily, and then sub obtions allow you to execute every x minutes or hours.|||

Great ! it works fine

|||Out of interest, what is it actually doing?

I'm just thinking that in some circumstances maybe it might be better to execute a package when some event occurs rather than continuously executing at defined intervals waiting for something to happen (if indeed this is what it is doing).

Another option might be the WMI EventWatcher task.

Just speculating of course...

-Jamie|||I use it to download stock quotes published on http server...|||Fair enough. SQL Agent is probably your best option then. I'll shutup now

||| I'm beginner then i listen everyone... your remarks are welcome....

ps : excuse my french accent...|||

Coroebus wrote:

I'm beginner then i listen everyone... your remarks are welcome....

ps : excuse my french accent...

Your english is alot better than that of other people I have seen on many technical forums that speak it as their first language. Don't worry about that!

Planning ahead w/ SQL Server...

With the current web app that I am writing, I am starting to plan ahead to the scalability problems that I am planning on encountering with the number of users that I may have...

My hosting plan now allows for a 50MB SQL Server database, but, I know that will not last long, each user will be using 3-5MB each of the database, so I am going to outgrow my space fast.

Would looking into (until i have enough subscribers to get a dedicated host), SQL Hosting be a good idea? Atleast to start off with something like http://www.alentus.com/hosting/sqlserver.asp ?

But then again, would a SQL Database growing to large get bad? Within a few years, i expect to have at max 5,000 users, so that could grow to a 25GB database... with millions of rows.

Would breaking it up into smaller databases for each N amount of users be a wise idea? Or would it not really matter?

Any help is much appreciated

Happy New Year
Harold.Sql Server can easily handle huge amounts of data. In the schema of things 25 Gb and millions of rows isn't that big, particularly if the data is organized correctly and you have appropriate indexes defined. Breaking it up into smaller databases won't really help you and it would create a maintenance headache.

Of greater importance would be planning for the type of database server to handle future needs. But to start off with almost any decent server will do.

planning a replication

hallo
we have a sql2000 in the headquarter, and 3 new remote branches opening in few weeks with no sql servers installed yet.
We plan to setup a merge replica. The headquarter will have the highest activity on the replicated tables.
Shall we use all SQL2000 in the remote branches? Or could we use SQL2005, using a 2005 as a publisher and distributor?
TIA

If possible, upgrade all your nodes to SQL 2005. Merge replication performs and scales much better with the new pre-computed partitions. If this is not possible, then the only supported configuration is that the version of the distributor >= version of the publisher >= version of the subscriber. You can find more info about this in topic Using Multiple Versions of SQL Server in a Replication Topology".

|||ok thanks.
we're not going to upgrade the only sql2000 server we have, but i'd prefere to use sql2005 in the remote branches: in this scenario, i could set one of the 2005 as distributor and publisher.
This would be in contrast with the network topology, that centers everything in the main plant; BTW there will not be a big traffic of replicated data: a theoretical maximum of about 10 records/minute.

Placing Filegroups on separate drives

Hi All,

I have adatabase which is over 150GB in size and an estimated size of 1 Terabyte. I am planning to split the database into various filegroups. I have already separated the indexes and data from the Database. My Tempdb is in separate physical drive.

I was thinking if it’s a good idea to place each filegroup into a separate drive. The drives are not physical drives but partitioned, however the drive I portioned is raid 1+0.

Would I get any great performance benefit of placing filegroups on their own drives ?

Placing the filegroup structure below.

No

Filegroup

Drive

1

PRIMARY

F

2

LOG

J

3

AD_Data

G

4

AD_Indexes

H

5

CV_Data

I

6

CV_Indexes

J

7

DIM_Data

K

8

DIM_Indexes

L

9

FACT_Data

M

10

FACT_Indexes

N

11

STAGING_Data

O

12

STAGING_Indexes

P

13

ORG_Data

Q

14

ORG_Indexes

R

15

TMP_Data

S

16

TMP_Indexes

T

Any help would be appreciated

Thx

It depends whether these drives have separate controllers or not. If so, then its possible that a query accessing data in separate files groups will use multiple contollers so the data can be access simultaneously giving better performance. If they all use the same controller then performance will be be helped. If one or more tend to grow more quickly they could be put on separate drives and auth growth paramters might be different but that really isn't peformance related unless auto growth occurs during an INSERT or UPDATE. It may be faster to autogrow one smaller filegroup than one huge database.

My 2 cents