Processing methodology

we have 3 large fact tables with combined rec cnts of 32 million. These 3 fact tables share order attribute that we would like to pull out and create a order dimension so that the facts tables don't have to contain the attributes. I've tried update processing of this dimension but the time it takes is not much different than a full process. I would like to know if there is anything like a incremental processing of this dimension and how would I set that up?

I assume that you are using Analysis Services 2005?

Actually, the "Process Update" method is slow than doing a "Process Full" on a dimension. The reason for this is, that "Process Update" reads the entire dimension table and compares the content of this with the existing, processed dimension. Any differences are then updated in the OLAP dimension. "Process Full", on the other hand, does not have to make any comparisons - it simply reads the entire dimension table and builds the OLAP dimension.

Now, the main reason for using "Process Update" is that is does not invalidate your processed measure groups. If you do a "Process Full" on the dimension, you are forced into doing a "Process Full" on any measure group that contains this dimension. Note, that "Process Update" will invalidate the aggregations on any associated measure group, provided that changes have occured to the dimension. This means, that a "Process Update" on the dimension will have to be followed by a "Process Index" on the associated measure groups in order to get aggregations back.

Process order for changing IPs of network adapters and SQL services

A change in networking if forcing all of our IPs to change. I have
found KB articles 230356 and 244980 with the processes for changing the
IP addresses of the network adapters and SQL virtual servers
separately, but I would like to make sure I have the overall process
order correct.
Is there documentation available that describes the steps when _all_ of
the IPs involved in a cluster change, both physical and virtual?
Ouch. I went through this once before. While I don't have a step-by-step
process, the key is to only mess up one network at a time. Make sure you
have enabled private communications on both the public and private cluster
networks. While you are changing one network the cluster can continue to
communicate on the other one. Make sure the cluster can communicate on the
modified network before changing the unmodified one.
My biggest problem was changing the IP addresses of the SAN and re-linking
to the host nodes.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<bsg075@.gmail.com> wrote in message
news:1124126624.137059.189680@.z14g2000cwz.googlegr oups.com...
>A change in networking if forcing all of our IPs to change. I have
> found KB articles 230356 and 244980 with the processes for changing the
> IP addresses of the network adapters and SQL virtual servers
> separately, but I would like to make sure I have the overall process
> order correct.
> Is there documentation available that describes the steps when _all_ of
> the IPs involved in a cluster change, both physical and virtual?
>

Procedure to Stress Test

Could someone write for exact SQL statment to stress test my tempDB, or
production.db?
(assume physical location is E:\Data\tempdb.MDF)
In order to test exact size of productionDB, should I copy the mdf file,
rename, and attached as different database to do it?
ThanksThere is no single exact SQL statement to stress your database, tempdb or
otherwise. One of the easiest ways is stress a database is to run a variety
of SQL statements using multiple clients concurrently. The more clients you
can run, the more stress you can put on the database, within reason. But of
course your SQL statments could be poorly written so that they end up not
stressing the database but generating just overhead.
Linchi
"MC" wrote:
> Could someone write for exact SQL statment to stress test my tempDB, or
> production.db?
> (assume physical location is E:\Data\tempdb.MDF)
> In order to test exact size of productionDB, should I copy the mdf file,
> rename, and attached as different database to do it?
> Thanks
>
>|||Check out LoadRunner from Mercury.

Procedure to Stress Test

Could someone write for exact SQL statment to stress test my tempDB, or
production.db?
(assume physical location is E:\Data\tempdb.MDF)
In order to test exact size of productionDB, should I copy the mdf file,
rename, and attached as different database to do it?
ThanksThere is no single exact SQL statement to stress your database, tempdb or
otherwise. One of the easiest ways is stress a database is to run a variety
of SQL statements using multiple clients concurrently. The more clients you
can run, the more stress you can put on the database, within reason. But of
course your SQL statments could be poorly written so that they end up not
stressing the database but generating just overhead.
Linchi
"MC" wrote:

> Could someone write for exact SQL statment to stress test my tempDB, or
> production.db?
> (assume physical location is E:\Data\tempdb.MDF)
> In order to test exact size of productionDB, should I copy the mdf file,
> rename, and attached as different database to do it?
> Thanks
>
>|||Check out LoadRunner from Mercury.

Procedure to Stress Test

Could someone write for exact SQL statment to stress test my tempDB, or
production.db?
(assume physical location is E:\Data\tempdb.MDF)
In order to test exact size of productionDB, should I copy the mdf file,
rename, and attached as different database to do it?
Thanks
There is no single exact SQL statement to stress your database, tempdb or
otherwise. One of the easiest ways is stress a database is to run a variety
of SQL statements using multiple clients concurrently. The more clients you
can run, the more stress you can put on the database, within reason. But of
course your SQL statments could be poorly written so that they end up not
stressing the database but generating just overhead.
Linchi
"MC" wrote:

> Could someone write for exact SQL statment to stress test my tempDB, or
> production.db?
> (assume physical location is E:\Data\tempdb.MDF)
> In order to test exact size of productionDB, should I copy the mdf file,
> rename, and attached as different database to do it?
> Thanks
>
>
|||Check out LoadRunner from Mercury.