Please advise cluster configuration

We have datawarehouse servwer with Active/Active cluster.
One node has 8GB Ram and another node has 12GB.
Right now I have configured for both the nodes the Max.Sql Server Memory to
be 8GB.
Both the nodes are running with windows 2003 SP1and SQL Server 2000 SP4 with
the 8 CPU.
Please advise the best configuration for this.
Thanks.
Best practice is that you keep the Hardware configuration of all your
cluster nodes the same.
Assuming that you already have the /PAE switch in your boot.ini file, I
would recommend that you add 4GB ram to the node with only 8GB ram.
"DKRReddy" <dkrreddy@.hotmail.com> wrote in message
news:%23UPSxwbNHHA.4152@.TK2MSFTNGP06.phx.gbl...
> We have datawarehouse servwer with Active/Active cluster.
> One node has 8GB Ram and another node has 12GB.
> Right now I have configured for both the nodes the Max.Sql Server Memory
to
> be 8GB.
> Both the nodes are running with windows 2003 SP1and SQL Server 2000 SP4
with
> the 8 CPU.
> Please advise the best configuration for this.
> Thanks.
>
|||Here, here to Edwin's recommendations.
Moreover, you did not say if this installation was x86 or IA-64.
If the former, you will need to set AWE enabled for the BPool to be able to
address more than 4 GB and you will want to limit each node to only 1/2 (or
slightly less) than available memory.
If the latter, and you are not running with Lock Pages in Memory, then you
could specify the full memory amount on each node, but you might want to
also specify a minimum memory amount as well. The Itanium build is more
aggressive about acquiring the minimum memory setting and will cause the
other instance to give up excess memory more readily.
The reason is that in a multi-instanced configuration, there will be times
when you will need or have to have multiple instances running on a single
node, and you will need available resources for each.
Sincerely,
Anthony Thomas

"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:eyyfUfiNHHA.4720@.TK2MSFTNGP03.phx.gbl...
> Best practice is that you keep the Hardware configuration of all your
> cluster nodes the same.
> Assuming that you already have the /PAE switch in your boot.ini file, I
> would recommend that you add 4GB ram to the node with only 8GB ram.
>
> "DKRReddy" <dkrreddy@.hotmail.com> wrote in message
> news:%23UPSxwbNHHA.4152@.TK2MSFTNGP06.phx.gbl...
> to
> with
>
sql

placement of Analysis service? on cluster or lone server?

Hi, we have an active/passive cluster which hosts our production database.
Transactional replication is being made from the production to a 'reporting'
database residing on a lone server. We will need to install Analysis service
for the construction of cubes.
I was wondering where Analysis service should be installed?
Is is ok to install it on the lone server and have it use the data from the
reporting database (which is filled via transactional replication)? Will
Analysis service have a problem with this based on the fact that it is
reading a read only database which doesnt have primary keys in the tables?
OR, should analysis service be installed on the cluster? Is it cluster
aware?
At this stage we are thinking of only running the cubes at night to generate
the data for export to reporting service.
Would it then be a good idea to install reporting service on this same lone
server?
Any insight would be most appreciated!
Cheers, john
If that is the case, you can't possibly be running transactional
replication.
The "reporting" database is LOGICALLY read-only, not physically read-only.
This database also MUST have all of the primary keys in place on the tables,
since it is impossible to replicate a table with transactional replication
if the table does not have a primary key. This primary key exists at both
the publisher and the subscriber.
Analysis Services is not going to write to your tables when building cubes,
so it does not care if the tables are physically read-only, logically
read-only, or read-write.
Where you place AS is entirely up to you. You can install it on the
stand-alone server and you can install it in the cluster. The question you
need to ask is what level of availability do you need for AS. If it needs
to be available as much as possible, even through a hardware failure, then
it should be installed in the cluster. If not, it should be installed on
the stand-alone machine.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"john clarke" <jclarke@.nospam.com> wrote in message
news:%23QyI71JDGHA.688@.TK2MSFTNGP11.phx.gbl...
> Hi, we have an active/passive cluster which hosts our production database.
> Transactional replication is being made from the production to a
> 'reporting'
> database residing on a lone server. We will need to install Analysis
> service
> for the construction of cubes.
> I was wondering where Analysis service should be installed?
> Is is ok to install it on the lone server and have it use the data from
> the
> reporting database (which is filled via transactional replication)? Will
> Analysis service have a problem with this based on the fact that it is
> reading a read only database which doesnt have primary keys in the tables?
> OR, should analysis service be installed on the cluster? Is it cluster
> aware?
> At this stage we are thinking of only running the cubes at night to
> generate
> the data for export to reporting service.
> Would it then be a good idea to install reporting service on this same
> lone
> server?
> Any insight would be most appreciated!
> Cheers, john
>
>

PK Index Cluster/Non Cluster

I have application that I inherited. Looks to me the indexes where set up
incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys that
were set up with Identity Incremented by 1.
I was told the primary keys that are increasing in numerical value should be
a cluster index.
Is there a list of rules for best practices on setting up Cluster and
Non-Indexes?
Thanks,Most of the time yes, it probably would be clustered. But just because it's
not doesnt mean its incorrect. In a reporting server, you may want clusterin
g
done on date fields, as thats what most queries are run against and that
could greatly speed stuff up.
TIA,
ChrisR
"Joe K." wrote:

> I have application that I inherited. Looks to me the indexes where set u
p
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys tha
t
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should
be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,|||Here's my shortlist of reasons why identities make for excellent clustered
indexes:
(a) They're narrow - because the keys of a clustered index CIX) are also
stored in the leaf nodes of all non-clustered indexes (NCIX), the narrower
the CIX keys, the less size impact they'll have on the size of the NCIX's.
Identities can be any of the integer types, sos their size can vary, but in
general, a 4 byte integer key makes for a nice compact key.
(b) Unique - SQL Server "uniquefies" non-unique values in CIXs with 8 byte
uniquefiers. Because identities are reasonably unique, they don't suffer
from this problem.
(c) Incremental - because identity columns are generally incremental in
nature, you typically don't suffer much from fragmentation. Non-incremental
keys (eg, customername) can heavily fragment a database during insert /
update / delete operations
(d) Stable - if a CIX key gets updated, any associated NCIXs (on the same
table) also have to be updated to synchronise their CIX bookmark keys (as
described in (a) )
Regards,
Greg Linwood
SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:7E115D53-5D47-410E-9900-FE935FE397D6@.microsoft.com...
> I have application that I inherited. Looks to me the indexes where set
> up
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys
> that
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should
> be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,

PK Index Cluster/Non Cluster

I have application that I inherited. Looks to me the indexes where set up
incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys that
were set up with Identity Incremented by 1.
I was told the primary keys that are increasing in numerical value should be
a cluster index.
Is there a list of rules for best practices on setting up Cluster and
Non-Indexes?
Thanks,Most of the time yes, it probably would be clustered. But just because it's
not doesnt mean its incorrect. In a reporting server, you may want clustering
done on date fields, as thats what most queries are run against and that
could greatly speed stuff up.
TIA,
ChrisR
"Joe K." wrote:
> I have application that I inherited. Looks to me the indexes where set up
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys that
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,|||Here's my shortlist of reasons why identities make for excellent clustered
indexes:
(a) They're narrow - because the keys of a clustered index CIX) are also
stored in the leaf nodes of all non-clustered indexes (NCIX), the narrower
the CIX keys, the less size impact they'll have on the size of the NCIX's.
Identities can be any of the integer types, sos their size can vary, but in
general, a 4 byte integer key makes for a nice compact key.
(b) Unique - SQL Server "uniquefies" non-unique values in CIXs with 8 byte
uniquefiers. Because identities are reasonably unique, they don't suffer
from this problem.
(c) Incremental - because identity columns are generally incremental in
nature, you typically don't suffer much from fragmentation. Non-incremental
keys (eg, customername) can heavily fragment a database during insert /
update / delete operations
(d) Stable - if a CIX key gets updated, any associated NCIXs (on the same
table) also have to be updated to synchronise their CIX bookmark keys (as
described in (a) )
Regards,
Greg Linwood
SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:7E115D53-5D47-410E-9900-FE935FE397D6@.microsoft.com...
> I have application that I inherited. Looks to me the indexes where set
> up
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys
> that
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should
> be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,

PK Index Cluster/Non Cluster

I have application that I inherited. Looks to me the indexes where set up
incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys that
were set up with Identity Incremented by 1.
I was told the primary keys that are increasing in numerical value should be
a cluster index.
Is there a list of rules for best practices on setting up Cluster and
Non-Indexes?
Thanks,
Most of the time yes, it probably would be clustered. But just because it's
not doesnt mean its incorrect. In a reporting server, you may want clustering
done on date fields, as thats what most queries are run against and that
could greatly speed stuff up.
TIA,
ChrisR
"Joe K." wrote:

> I have application that I inherited. Looks to me the indexes where set up
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys that
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,
|||Here's my shortlist of reasons why identities make for excellent clustered
indexes:
(a) They're narrow - because the keys of a clustered index CIX) are also
stored in the leaf nodes of all non-clustered indexes (NCIX), the narrower
the CIX keys, the less size impact they'll have on the size of the NCIX's.
Identities can be any of the integer types, sos their size can vary, but in
general, a 4 byte integer key makes for a nice compact key.
(b) Unique - SQL Server "uniquefies" non-unique values in CIXs with 8 byte
uniquefiers. Because identities are reasonably unique, they don't suffer
from this problem.
(c) Incremental - because identity columns are generally incremental in
nature, you typically don't suffer much from fragmentation. Non-incremental
keys (eg, customername) can heavily fragment a database during insert /
update / delete operations
(d) Stable - if a CIX key gets updated, any associated NCIXs (on the same
table) also have to be updated to synchronise their CIX bookmark keys (as
described in (a) )
Regards,
Greg Linwood
SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:7E115D53-5D47-410E-9900-FE935FE397D6@.microsoft.com...
> I have application that I inherited. Looks to me the indexes where set
> up
> incorrectly. Numerous tables have Non-Cluster indexes as Primary Keys
> that
> were set up with Identity Incremented by 1.
> I was told the primary keys that are increasing in numerical value should
> be
> a cluster index.
> Is there a list of rules for best practices on setting up Cluster and
> Non-Indexes?
> Thanks,