Showing posts with label usage. Show all posts
Showing posts with label usage. Show all posts

Friday, March 30, 2012

Mapping two measure groups with different dimension usage

Hello.

I am looking for a solution for the following situation:

I have a measure group for my business facts and a measure group for tolerances and targets.

The first measure group uses a date dimension, a site dimension, a project dimension and an employee dimension.

The second group shares all dimensions except the employee dimension.

Lets say I have the business fact sales per hour.
The target value for this fact is stored in the second measure group without the employee info. The targets are valid for all employees at that site, project and day.

When i browse the cube i want see the targets next to the actual data - even on employee level.

Therefore i have to set IgnoreUnrelatedDimensions in the properties of the second measure group to True.
But when i do this i get an entry for every employee present in the employee dimension, showing the tolerance and target.

I am lost at the moment and belive that there must be an elegant solution. Hopefully someone has an idea?

Thanks,
ThomasFrom your description, it's not clear in which cases the IgnoreUnrelatedDimensions doesn't meet your needs - could you describe some scenarios? You could selectively use the MDX ValidMeasure() function in calculations, instead of applying IgnoreUnrelatedDimensions.|||Hello Deepak.

Thanks for your reply.

I'll try to explain my problem better with an example.

Data in my Tolerance FactTable:

DateProjectSiteTolerance_Sales_per_Hour20070320Upsell1Hamburg220070321Upsell1Hamburg220070322Upsell1Hamburg3

Data in my Sales FactTable:

DateProjectSiteEmployeeSales_Per_Hour20070320Upsell1HamburgBob1.520070320Upsell1HamburgMike2.120070321Upsell1HamburgBob2.720070321Upsell1HamburgMike3.320070322Upsell1HamburgBob1.2

When I select 20070322 as Date in the Browser, i get a row for Mike, although he dind't work on 22th.

DateProjectSiteEmployeeSales_Per_HourTolerance_Sales_per_Hour20070322Upsell1HamburgBob1.2320070322Upsell1HamburgMike3

Thanks to a tip from Markus i am using Scope-Statements at the moment

SCOPE([Measures].[Tolerance_Sales_Per_Hour]);
THIS=IIF (ISEMPTY([Measures].[Sales_Per_Hour]),NULL,[Tolerance_Sales_Per_Hour]);
END SCOPE;


But we are not sure, if this is the best solution.

Best regards,
Thomas

Wednesday, March 7, 2012

Managing memory usage of MSDE

I am getting ready to deploy a manufacturing application that uses a SQL2K
MSDE database. It is not a very large database but it gets updates every few
seconds, so it is very active.
When I first start the application, the total memory allocated to SQL (as
seen in task manager) is about 6M. this is before any transactions stat with
the application.
Once the transactions start, the memory usage grows consistantly. After
about 12hours of operation, the usage is over 600M (per Task Manager).
My question is, is this normal? Can it be controlled? If so, how? If not,
what options do I have to manage this?
It becomes a problem when the PC running the application must start caching
resources in order to maintain SQL performance.
Thanks in advance for your help...
hi rick,
"rick" <rick@.discussions.microsoft.com> ha scritto nel messaggio
news:E22FF67D-E9C5-4537-BC6B-DD18B697EF84@.microsoft.com
> I am getting ready to deploy a manufacturing application that uses a
> SQL2K MSDE database. It is not a very large database but it gets
> updates every few seconds, so it is very active.
> When I first start the application, the total memory allocated to SQL
> (as seen in task manager) is about 6M. this is before any
> transactions stat with the application.
> Once the transactions start, the memory usage grows consistantly.
> After about 12hours of operation, the usage is over 600M (per Task
> Manager).
> My question is, is this normal? Can it be controlled? If so, how? If
> not, what options do I have to manage this?
> It becomes a problem when the PC running the application must start
> caching resources in order to maintain SQL performance.
> Thanks in advance for your help...
please have a look at http://tinyurl.com/5qrjf about memory requirements,
and please keep in mind SQL Server works at best when it's running, alone,
on a database server, physically separated from an application server, print
server and so on..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||"Andrea Montanari" wrote:

> hi rick,
> "rick" <rick@.discussions.microsoft.com> ha scritto nel messaggio
> news:E22FF67D-E9C5-4537-BC6B-DD18B697EF84@.microsoft.com
> please have a look at http://tinyurl.com/5qrjf about memory requirements,
> and please keep in mind SQL Server works at best when it's running, alone,
> on a database server, physically separated from an application server, print
> server and so on..
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
Thanks for the reply, and I know that this is typically the case, but for
this application's requirements and the infrastructure that I have built,
keeping the MSDE on the same box as the application is critical. The MSDE is
only used for local storage as a buffer area for data replication to the
enterprise server and only when the Enterprise server requests the
information (based on network traffic, data popularity, and other metrics).
I found the stored procedure 'sp_configure' and the 'max server memory'
parameter and applied it according to the needs of the system. Efficiency may
be degraded slightly compared to a system that is stacked full of RAM, but
for the type of machine that this is running on, limitting the server memory
usage does not hurt performance as much as dik caching does.
Thanks for the reply though...