Project Server databases move to network storage - any specialconsiderations?

[anovak]

Other than whatever a DBA normally does on the SQL Server 2005 side to
move databases to a different drive letter, are there any steps that
need to be taken on the application side to ensure things are in sync?

For those DBAs out there, is it simply about moving the data files
that the databases point to, or more than that?

Currently, our databases "live" on the C: drive of a dedicated
physical SQL Server 2005 box. Project Server is in a VMWare VM that
"lives" on another box. We wish to instigate a change where all the
data "lives" on another (SAN) drive rather than the local C: drive.

Thanks,
Andy Novak
UNT

 

[Ben]

Assuming that you are keeping the SQL Application server name the same, then
there are no other considerations to take account of.

 

[Rudolf]

Hi Andy,

first of all I want you to know that I have no live experience with
the case you describe, but considering...

with only changing the drive letters for the databases, I see no
problem.
Because, if I had a server with three drives: C, E and F for instance
and drive E would turn out to be too small, I could move the databases
to drive F without any problem.

This is, of course, because the database names or server do
not change in this case.

But if you move the databases to another server, the odds are against
you.
This is because the sharepoint farm is actually denoted by the sql
server that hosts the databases.
This means, I think, that the sharepoint configuration database should
be aware of the sql server it is running on.
Than, simply moving such a configuration database will do no good.
And, at least, a partial reinstall has to be performed.
(Same argument goes for the search database.)

I suggest to build a test environment, so you can see what happens.
I really don't know if sharepoint is by it self intelligent enough to
realize it has been moved to another server.
And personally I wouldn't count on it.

Aside from this you should really browse the internet, there is lot of
info that will help you to choose the right direction.

Mind you, - at leat this I know from experience -, even reinstalling
the sharepoint and project server databases to the original machine,
-like after a crash-, can cause the project server queue service or
the shared service provider to be inreliable or simply not working.

HTH,
Rudolf

 

[anovak]

Hi Andy,

first of all I want you to know that I have no live experience with
the case you describe, but considering...

with only changing the drive letters for the databases, I see no
problem.
Because, if I had a server with three drives: C, E and F for instance
and drive E would turn out to be too small, I could move the databases
to drive F without any problem.

This is, of course, because the database names or server do
not change in this case.

But if you move the databases to another server, the odds are against
you.
This is because the sharepoint farm is actually denoted by the sql
server that hosts the databases.
This means, I think, that the sharepoint configuration database should
be aware of the sql server it is running on.
Than, simply moving such a configuration database will do no good.
And, at least, a partial reinstall has to be performed.
(Same argument goes for the search database.)

I suggest to build a test environment, so you can see what happens.
I really don't know if sharepoint is by it self intelligent enough to
realize it has been moved to another server.
And personally I wouldn't count on it.

Aside from this you should really browse the internet, there is lot of
info that will help you to choose the right direction.

Mind you, - at leat this I know from experience -, even reinstalling
the sharepoint and project server databases to the original machine,
-like after a crash-, can cause the project server queue service or
the shared service provider to be inreliable or simply not working.

HTH,
Rudolf

No change whatsoever in the server name, etc. Just moving the content
to the SAN from the C: drive. So, its strictly DBA type work then
with no changes to the app?