Clustering installation issue

I'm trying to install SQL 2000 on a newly clustered Win2000 system.

I'm getting the following error:
The drive chosen for the program files installation path, C:, is not valid on all nodes of the cluster. Choose another drive to install the program files.

I've read Microsoft's explanation of the error, and that the one server can't access the C: drive of the other server if file and print sharing isn't setup correctly. However...

I'm logged on as Administrator, and have full control of both machines.
I'm telling the SQL install to use the administrator account.
If I go to start->run-> and type \\serverB\C$ the share opens just fine.
I've also check the registry entries that MS suggests: HKey_LocalMachine\Software\Microsoft\Windows\Curre ntVersion and make sure that the value for CommonFilesDir and ProgramFilesDir is the same on both the nodes. They're the same

I am trying to install the data files within the same group as the quorom drive, but that should just give me a warning (and it does) and shouldn't be this problem. I'm just trying to install to the system drive (C:) which certainly exists on both machines.

I've seen a couple other posts about this, but no solutions. Any help would be great.

Thanks,
MattReview this http://support.microsoft.com/default.aspx?scid=kb;[LN];Q279642] to take care of further installation.|||Satya,

I tried the link that you provided, but got to a Microsoft page that said that page no longer exists.

If it's the KB article:
Microsoft Knowledge Base Article - 279642

I have already gone through that without any luck. But if it's something else, I'd be happy to try it.

Also, I have since been able to get the installation to work if instead of using the C: drive, I use the drive dedicated to the page file. Obviously, this isn't something I'd want to do, but hopefully it provides more information that might help someone figure out what my issue is.

Thanks,
matt|||You cn install the program files to the C:\ drive, but all data has to be installed on a shared drive. Are you selecting custom install with Data going to a shared drive?|||Further help from here (http://www.sql-server-performance.com/wndows2000_clustering_install_main.asp)

HTH|||Well, I have no idea what this issue was, but to get around it you can:

Install SQL Server locally to one of the nodes of the cluster.
Be sure to put the data files on a drive that is part of the cluster.
Then upgrade the local instance to a clustered instance.

All worked for me, using that strange process.

Clustered SQL 2005 Standard

I just completed an install of SQL 2005 Standard into a newly formed
cluster. I basically installed every option for SQL 2005 Server, however,
the only resources added to the cluster group were SQL Server, SQL Agent and
SQL Server Fulltext.
I would have thought reporting services would have been put in there as
well. Is this something I have to add later, or install on each node
separately?
Also forgot to mention, after the install, it didn't put any of the System
DB's into the drive\folder I specified.
So, now I have to go and move them...
Does anyone know of an online tutorial for the new SQL 2005 Interface?
"Kevin Antel" <kevina@.cqlcorp.com> wrote in message
news:eTJ3ULSHGHA.3624@.TK2MSFTNGP09.phx.gbl...
>I just completed an install of SQL 2005 Standard into a newly formed
>cluster. I basically installed every option for SQL 2005 Server, however,
>the only resources added to the cluster group were SQL Server, SQL Agent
>and SQL Server Fulltext.
> I would have thought reporting services would have been put in there as
> well. Is this something I have to add later, or install on each node
> separately?
>
|||Reporting Services is not failover clusterable. It will need to be
installed on each node separately. Since it is a web service, you are
better off setting up a load-balanced web farm with the databases on a
clustered server.
From your followup question: BOL contains some excellent tutorals including
a section on SQL Server Tools.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Kevin Antel" <kevina@.cqlcorp.com> wrote in message
news:eTJ3ULSHGHA.3624@.TK2MSFTNGP09.phx.gbl...
>I just completed an install of SQL 2005 Standard into a newly formed
>cluster. I basically installed every option for SQL 2005 Server, however,
>the only resources added to the cluster group were SQL Server, SQL Agent
>and SQL Server Fulltext.
> I would have thought reporting services would have been put in there as
> well. Is this something I have to add later, or install on each node
> separately?
>
|||Thanks.
How about moving all the DB's to the appropriate drives now?
Looks like it's a little different then in 2000.
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:O2kLMmSHGHA.344@.TK2MSFTNGP11.phx.gbl...
> Reporting Services is not failover clusterable. It will need to be
> installed on each node separately. Since it is a web service, you are
> better off setting up a load-balanced web farm with the databases on a
> clustered server.
> From your followup question: BOL contains some excellent tutorals
> including a section on SQL Server Tools.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Kevin Antel" <kevina@.cqlcorp.com> wrote in message
> news:eTJ3ULSHGHA.3624@.TK2MSFTNGP09.phx.gbl...
>
|||ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/72bb62ee-9602-4f71-be51-c466c1670878.htm
Note: This is a link from the December 2005 BOL Refresh for SQL Server
2005. If you are using the RTM BOL, it may not work correctly.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Kevin Antel" <kevina@.cqlcorp.com> wrote in message
news:e60JnoSHGHA.3408@.TK2MSFTNGP12.phx.gbl...
> Thanks.
> How about moving all the DB's to the appropriate drives now?
> Looks like it's a little different then in 2000.
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:O2kLMmSHGHA.344@.TK2MSFTNGP11.phx.gbl...
>

Clustered Index Question

sql2k sp3
If my Clustered Index is an Identity Coulmn, should
Inserts still be slowed down. In other words, since a
newly Inserted row should be stored at the end, why would
it be any slower than when theres no Clustered Index? It
shouldnt need to reorganize anything. Aslo, should
Updates be any slower since you cant Update an Identity
field anyways?
TIA, ChrisRActually it should be slightly faster than if it were just a heap. A heap
has to do some lookups to determine where to place the next row that have a
slight bit of overhead. A CI insert with a monotonically incrementing value
is a no brainer per say for SQL Server. As you stated it goes to the end of
the last page.
--
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> sql2k sp3
> If my Clustered Index is an Identity Coulmn, should
> Inserts still be slowed down. In other words, since a
> newly Inserted row should be stored at the end, why would
> it be any slower than when theres no Clustered Index? It
> shouldnt need to reorganize anything. Aslo, should
> Updates be any slower since you cant Update an Identity
> field anyways?
> TIA, ChrisR|||Would Updates be the same?
>--Original Message--
>Actually it should be slightly faster than if it were
just a heap. A heap
>has to do some lookups to determine where to place the
next row that have a
>slight bit of overhead. A CI insert with a
monotonically incrementing value
>is a no brainer per say for SQL Server. As you stated
it goes to the end of
>the last page.
>--
>Andrew J. Kelly SQL MVP
>
>"ChrisR" <anonymous@.discussions.microsoft.com> wrote in
message
>news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
>> sql2k sp3
>> If my Clustered Index is an Identity Coulmn, should
>> Inserts still be slowed down. In other words, since a
>> newly Inserted row should be stored at the end, why
would
>> it be any slower than when theres no Clustered Index?
It
>> shouldnt need to reorganize anything. Aslo, should
>> Updates be any slower since you cant Update an Identity
>> field anyways?
>> TIA, ChrisR
>
>.
>|||It depends on which columns you modify. If you modify a column which is part of the clustered index,
the row need to be moved. If you modify a column which is part of a non-clustered index, then the
non-clustered index need to be modified accordingly.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:254001c4a4d8$6d1a0710$a501280a@.phx.gbl...
> Would Updates be the same?
>
>>--Original Message--
>>Actually it should be slightly faster than if it were
> just a heap. A heap
>>has to do some lookups to determine where to place the
> next row that have a
>>slight bit of overhead. A CI insert with a
> monotonically incrementing value
>>is a no brainer per say for SQL Server. As you stated
> it goes to the end of
>>the last page.
>>--
>>Andrew J. Kelly SQL MVP
>>
>>"ChrisR" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
>> sql2k sp3
>> If my Clustered Index is an Identity Coulmn, should
>> Inserts still be slowed down. In other words, since a
>> newly Inserted row should be stored at the end, why
> would
>> it be any slower than when theres no Clustered Index?
> It
>> shouldnt need to reorganize anything. Aslo, should
>> Updates be any slower since you cant Update an Identity
>> field anyways?
>> TIA, ChrisR
>>
>>.|||Did Karen mention something about "hot spots" if using clustered identity
column in her book? I have to look it up...
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:#tM$WXNpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> Actually it should be slightly faster than if it were just a heap. A heap
> has to do some lookups to determine where to place the next row that have
a
> slight bit of overhead. A CI insert with a monotonically incrementing
value
> is a no brainer per say for SQL Server. As you stated it goes to the end
of
> the last page.
> --
> Andrew J. Kelly SQL MVP
>
> "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> > sql2k sp3
> >
> > If my Clustered Index is an Identity Coulmn, should
> > Inserts still be slowed down. In other words, since a
> > newly Inserted row should be stored at the end, why would
> > it be any slower than when theres no Clustered Index? It
> > shouldnt need to reorganize anything. Aslo, should
> > Updates be any slower since you cant Update an Identity
> > field anyways?
> >
> > TIA, ChrisR
>|||Who's Karen? What book?
>--Original Message--
>Did Karen mention something about "hot spots" if using
clustered identity
>column in her book? I have to look it up...
>
>"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in
message
>news:#tM$WXNpEHA.1668@.TK2MSFTNGP14.phx.gbl...
>> Actually it should be slightly faster than if it were
just a heap. A heap
>> has to do some lookups to determine where to place the
next row that have
>a
>> slight bit of overhead. A CI insert with a
monotonically incrementing
>value
>> is a no brainer per say for SQL Server. As you stated
it goes to the end
>of
>> the last page.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "ChrisR" <anonymous@.discussions.microsoft.com> wrote
in message
>> news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
>> > sql2k sp3
>> >
>> > If my Clustered Index is an Identity Coulmn, should
>> > Inserts still be slowed down. In other words, since a
>> > newly Inserted row should be stored at the end, why
would
>> > it be any slower than when theres no Clustered
Index? It
>> > shouldnt need to reorganize anything. Aslo, should
>> > Updates be any slower since you cant Update an
Identity
>> > field anyways?
>> >
>> > TIA, ChrisR
>>
>
>.
>|||It's Kalen Delaney and her book is "Inside SQL Server 2000" which every good
dba should have a copy of...
--
Andrew J. Kelly SQL MVP
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:03ec01c4a4ea$a9707ac0$a601280a@.phx.gbl...
> Who's Karen? What book?
>
> >--Original Message--
> >Did Karen mention something about "hot spots" if using
> clustered identity
> >column in her book? I have to look it up...
> >
> >
> >
> >"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in
> message
> >news:#tM$WXNpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> >> Actually it should be slightly faster than if it were
> just a heap. A heap
> >> has to do some lookups to determine where to place the
> next row that have
> >a
> >> slight bit of overhead. A CI insert with a
> monotonically incrementing
> >value
> >> is a no brainer per say for SQL Server. As you stated
> it goes to the end
> >of
> >> the last page.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "ChrisR" <anonymous@.discussions.microsoft.com> wrote
> in message
> >> news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> >> > sql2k sp3
> >> >
> >> > If my Clustered Index is an Identity Coulmn, should
> >> > Inserts still be slowed down. In other words, since a
> >> > newly Inserted row should be stored at the end, why
> would
> >> > it be any slower than when theres no Clustered
> Index? It
> >> > shouldnt need to reorganize anything. Aslo, should
> >> > Updates be any slower since you cant Update an
> Identity
> >> > field anyways?
> >> >
> >> > TIA, ChrisR
> >>
> >>
> >
> >
> >.
> >|||In addition to Tibor's comments if you update a variable column it may make
the row too large to fit everything on the page and cause a split. But this
will happen regardless of the column the CI is on if the data won't fit.
--
Andrew J. Kelly SQL MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e1EmQnNpEHA.1712@.tk2msftngp13.phx.gbl...
> It depends on which columns you modify. If you modify a column which is
part of the clustered index,
> the row need to be moved. If you modify a column which is part of a
non-clustered index, then the
> non-clustered index need to be modified accordingly.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> news:254001c4a4d8$6d1a0710$a501280a@.phx.gbl...
> > Would Updates be the same?
> >
> >
> >>--Original Message--
> >>Actually it should be slightly faster than if it were
> > just a heap. A heap
> >>has to do some lookups to determine where to place the
> > next row that have a
> >>slight bit of overhead. A CI insert with a
> > monotonically incrementing value
> >>is a no brainer per say for SQL Server. As you stated
> > it goes to the end of
> >>the last page.
> >>
> >>--
> >>Andrew J. Kelly SQL MVP
> >>
> >>
> >>"ChrisR" <anonymous@.discussions.microsoft.com> wrote in
> > message
> >>news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> >> sql2k sp3
> >>
> >> If my Clustered Index is an Identity Coulmn, should
> >> Inserts still be slowed down. In other words, since a
> >> newly Inserted row should be stored at the end, why
> > would
> >> it be any slower than when theres no Clustered Index?
> > It
> >> shouldnt need to reorganize anything. Aslo, should
> >> Updates be any slower since you cant Update an Identity
> >> field anyways?
> >>
> >> TIA, ChrisR
> >>
> >>
> >>.
> >>
>|||Hi
Hot spotting used to be a bigger problem in pre SQL 2000 SP 2.
The storage engine team have done a lot of improvements in their quest for
better performance. The actual limitation is now the Page Allocation Map.
Unless yopu are pushing 1'000's of inserts per second, you won't have an
issue.
Standard rules apply, keep the transactions short and don't have excessive
indexes.
Regards
Mike
"Raymond Fang" wrote:
> Did Karen mention something about "hot spots" if using clustered identity
> column in her book? I have to look it up...
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:#tM$WXNpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> > Actually it should be slightly faster than if it were just a heap. A heap
> > has to do some lookups to determine where to place the next row that have
> a
> > slight bit of overhead. A CI insert with a monotonically incrementing
> value
> > is a no brainer per say for SQL Server. As you stated it goes to the end
> of
> > the last page.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> > news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> > > sql2k sp3
> > >
> > > If my Clustered Index is an Identity Coulmn, should
> > > Inserts still be slowed down. In other words, since a
> > > newly Inserted row should be stored at the end, why would
> > > it be any slower than when theres no Clustered Index? It
> > > shouldnt need to reorganize anything. Aslo, should
> > > Updates be any slower since you cant Update an Identity
> > > field anyways?
> > >
> > > TIA, ChrisR
> >
> >
>
>|||Mike, Thanks!
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:6DC591BA-8EC3-4F9F-BF43-993CB1BA534E@.microsoft.com...
> Hi
> Hot spotting used to be a bigger problem in pre SQL 2000 SP 2.
> The storage engine team have done a lot of improvements in their quest for
> better performance. The actual limitation is now the Page Allocation Map.
> Unless yopu are pushing 1'000's of inserts per second, you won't have an
> issue.
> Standard rules apply, keep the transactions short and don't have excessive
> indexes.
> Regards
> Mike
> "Raymond Fang" wrote:
> > Did Karen mention something about "hot spots" if using clustered
identity
> > column in her book? I have to look it up...
> >
> >
> >
> > "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> > news:#tM$WXNpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> > > Actually it should be slightly faster than if it were just a heap. A
heap
> > > has to do some lookups to determine where to place the next row that
have
> > a
> > > slight bit of overhead. A CI insert with a monotonically incrementing
> > value
> > > is a no brainer per say for SQL Server. As you stated it goes to the
end
> > of
> > > the last page.
> > >
> > > --
> > > Andrew J. Kelly SQL MVP
> > >
> > >
> > > "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> > > news:31d601c4a4d4$5d7139e0$a301280a@.phx.gbl...
> > > > sql2k sp3
> > > >
> > > > If my Clustered Index is an Identity Coulmn, should
> > > > Inserts still be slowed down. In other words, since a
> > > > newly Inserted row should be stored at the end, why would
> > > > it be any slower than when theres no Clustered Index? It
> > > > shouldnt need to reorganize anything. Aslo, should
> > > > Updates be any slower since you cant Update an Identity
> > > > field anyways?
> > > >
> > > > TIA, ChrisR
> > >
> > >
> >
> >
> >