Showing posts with label machine. Show all posts
Showing posts with label machine. Show all posts

Friday, March 23, 2012

Optimizations for machine dedicated to processing

Hello,

We have a machine entirely dedicated to processing SSAS 2005 cubes, and then other machines sync from it and provide client access.

I notice that sometimes during processing, the processor usage hovers at about 15% and there is no paging or disk activity, which makes me wonder if SSAS is somehow limiting resources used for processing. Are there any optimizations that can be made to tell SSAS to assume that it doesn't have to serve clients, and can devote all resources to processing? I'm looking specifically at the Thread Pool / Process / Priority Ratio, which it says is an advanced property not to be changed without guidance--could increasing this work?

Thanks for any ideas.

Tom

You should be able to use several tools to monitor what is happening during processing of Analysis Services cubes:

SQL Profiler- will show you trace events
ActivityViewer sample app- will show you current connections, sessions..

Try to see what stage of processing is going slow on your machine. In several cases I have seen Analysis Server sitting and waiting for data to come from relational database.

Processing of partition has several stages:
Read Data , Write Data , Build Index ...

See which part is under suspicion.

I wouldnt go changing advanced sever properties without talking to product support.

Hope that helps.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Wednesday, March 7, 2012

operating systems

Hello,
We aim to use the current server (w2k,sql2000ent, 2x1ghz, 1gb ram, mirrored
pair & raid 5 for data) as a failover machine and upgrade to a new server
for production.
The 2 machines will be in different countries. Users in both countries will
use the production server. If the connection between the countries is
broken, the remote users will use the failover.
We propose to have merge replication between the 2 machines (mainly one
way).
How can we estimate the physical physical size of data that would need to be
transferred to the failover m/c for a given time period?
Presumably it would make sense to use w2003 on both machines?
Do the operating systems on 2 merge replicating machines have to be the
same?
Any advice would be appreciated.
Thanks SOC.
I would not use merge for this - I would use bi-directional transactional
replication. This is ideal because your data is highly partitioned.
Transactions occur on only one side at a time.
Transactional replication is in general much faster than merge replication.
Transactional replication is designed for server to server replication -
whereas merge is designed for clients who often go offline. Merge
replication adds a GUID column to each table you are replicating.
Transactional requires a primary key on each table.
Merge replication can be more difficult to trouble shoot than transactional.
Merge also requires (in general) more processing than transactional.
This is not to say of course that merge is always less performant than
transactional or slower than transactional. If you have a solution where
there are heavy updates, the servers are not connected for significant
lengths of time, and transactions originate on one server - merge is faster
and performs better. Consider a stock market application where 1) the
majority of the transactions are updates 2) the servers connect once a day
3) the transactions all occur on the publisher - in this case merge performs
way better than tranny.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"soc" <zxc0@.yahoo.com> wrote in message
news:eWfg9uQ4EHA.2404@.TK2MSFTNGP14.phx.gbl...
> Hello,
> We aim to use the current server (w2k,sql2000ent, 2x1ghz, 1gb ram,
> mirrored pair & raid 5 for data) as a failover machine and upgrade to a
> new server for production.
> The 2 machines will be in different countries. Users in both countries
> will use the production server. If the connection between the countries is
> broken, the remote users will use the failover.
> We propose to have merge replication between the 2 machines (mainly one
> way).
> How can we estimate the physical physical size of data that would need to
> be transferred to the failover m/c for a given time period?
> Presumably it would make sense to use w2003 on both machines?
> Do the operating systems on 2 merge replicating machines have to be the
> same?
> Any advice would be appreciated.
> Thanks SOC.
>
|||Thanks Hilary,
I will look into bi-directional tranasactional replication.
-Presumably it would make sense to use w2003 on both machines?
-Do the operating systems on 2 replicating machines have to be the
same?
Any advice would be appreciated.
Thanks SOC.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:O8z42MR4EHA.4092@.TK2MSFTNGP14.phx.gbl...
>I would not use merge for this - I would use bi-directional transactional
>replication. This is ideal because your data is highly partitioned.
>Transactions occur on only one side at a time.
> Transactional replication is in general much faster than merge
> replication. Transactional replication is designed for server to server
> replication - whereas merge is designed for clients who often go offline.
> Merge replication adds a GUID column to each table you are replicating.
> Transactional requires a primary key on each table.
> Merge replication can be more difficult to trouble shoot than
> transactional. Merge also requires (in general) more processing than
> transactional.
> This is not to say of course that merge is always less performant than
> transactional or slower than transactional. If you have a solution where
> there are heavy updates, the servers are not connected for significant
> lengths of time, and transactions originate on one server - merge is
> faster and performs better. Consider a stock market application where 1)
> the majority of the transactions are updates 2) the servers connect once a
> day 3) the transactions all occur on the publisher - in this case merge
> performs way better than tranny.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> Now available for purchase at:
> http://www.nwsu.com/0974973602.html
> "soc" <zxc0@.yahoo.com> wrote in message
> news:eWfg9uQ4EHA.2404@.TK2MSFTNGP14.phx.gbl...
>
|||you do not have to have the same operating system. It is adviseable to use
NT server operating systems, ie NT 4., Win2k, and Win2003.
I think you can get away with using NT workstation, or XP professional but
there can be a connection limit you can bang into.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"soc" <zxc0@.yahoo.com> wrote in message
news:egaFkBT4EHA.2540@.TK2MSFTNGP09.phx.gbl...
> Thanks Hilary,
> I will look into bi-directional tranasactional replication.
> -Presumably it would make sense to use w2003 on both machines?
> -Do the operating systems on 2 replicating machines have to be the
> same?
> Any advice would be appreciated.
> Thanks SOC.
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:O8z42MR4EHA.4092@.TK2MSFTNGP14.phx.gbl...
>