Merge Data

Hi,

I have an analysis server which get his data from an AIX. We use reporting server to get some reports. Unfortenately the data on the AIX is incorrect. I created a table called "corrections" . The corrections should be merged with the data

Solution 1 : modify the data source view in SSAS and integrate the corrections

Solution 2: make a stored procedure that gets the data from SSAS and merges it with the correction. Call the SP from the report.

Which one is better ?

And how do you implement solution 1 ?

And where can I find books over creating MDX queries ?

With regards,

Constantijn Enders

Hello.

Solution1 will not be good enough. I recommend you to build a data warehouse and make your corrections in the ETL-process. Thats is when you load data from your source system to a data warehouse. About data warehouse pros and cons I recommend you to have a look here(www.kimballgroup.com)

About MDX books I can recommend to start with "Analysis Services 2005, Step by Step" that is a good start book to learn Analysis Services 2005 and some MDX.

A respected MDX expert and writer of articles in this area you can find here: http://www.databasejournal.com/features/article.php/3593466

Look for William E. Pearson

HTH

Thomas Ivarsson

|||

Thank you for the excellent information. It will surely help me

Constantijn

Memory usage in RS(ASP.NET worker process)

Hi all,

We have been experiencing a problem with a couple of our reports that a
number of people seem to have hit previously. Basically the issue is if
the report is over a certain size the ASP.NET worker process hits its
threshold (60%) and the process gets shut down. We have followed the
advice listed in some of the posts in increasing this threshold which
manages to get the report through but we still have a few concerns.

1. Why won't the process use virtual memory. It seems to be limted to
physical memory available and when we increased the threshold, if that
physical memory runs out we get an out of memory exception.

2. The memory doesn't appear to be being released, I would have
throught the garbage collection would kick in pretty soon after the
report was finished but watching the process the memory stays in use
for a large amount of time after the report has finised rendering, with
no new activity on the server.

3. How does this scale at all? I have seen the argument that reports of
this size are unfeasable, and agree to an extent... unfortunately our
clients don't and they need a system capable of delivering them all the
data, regardless of the size of the report. I also read a suggestion to
use DTS to deliver a csv file to the client, but this sounds like a one
off workaround, more than an ongoing process that say an end user could
intiate once a month (for a thousand or so different companies).

This leads me to my final concern.... We have observed that the memory
will pile up, ie if the user kicks off one report it uses x amount...
if another user kicks off another report that will use an additional
amount of memory.... so even if the report isn't too big, it would only
take ten users running medium size reports to run the server out of
memory.... does anyone have any suggestions as to how we should cater
for this?

Thanks in advance
Greg

We are still having issues in this regard, does anyone have any insights?

memory usage - pages or KB?

I have read conflicting reports that the number in the memory usage column under Current Processes is the number of pages and that it is the number of KB of allocated memory. Which one is correct? Thanks
It's (8 KB) pages. See the documentation for sysprocesses (from which the
information in Enterprise Manager is derived) in BOL.
Where did you read the information that it was KB instead of pages btw?
Jacco Schalkwijk
SQL Server MVP
"J Jetson" <JJetson@.discussions.microsoft.com> wrote in message
news:37D533A5-479A-48E6-A12A-7CF2E83883FB@.microsoft.com...
>I have read conflicting reports that the number in the memory usage column
>under Current Processes is the number of pages and that it is the number of
>KB of allocated memory. Which one is correct? Thanks
|||A couple of people had told me that, and one of them referenced this page:
http://www.microsoft.com/technet/pro.../c03ppcsq.mspx
but more sources say it is the number of pages so I will stick with that. Thanks.
"Jacco Schalkwijk" wrote:

> It's (8 KB) pages. See the documentation for sysprocesses (from which the
> information in Enterprise Manager is derived) in BOL.
> Where did you read the information that it was KB instead of pages btw?
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "J Jetson" <JJetson@.discussions.microsoft.com> wrote in message
> news:37D533A5-479A-48E6-A12A-7CF2E83883FB@.microsoft.com...
>
>

memory usage - pages or KB?

I have read conflicting reports that the number in the memory usage column u
nder Current Processes is the number of pages and that it is the number of K
B of allocated memory. Which one is correct? ThanksIt's (8 KB) pages. See the documentation for sysprocesses (from which the
information in Enterprise Manager is derived) in BOL.
Where did you read the information that it was KB instead of pages btw?
Jacco Schalkwijk
SQL Server MVP
"J Jetson" <JJetson@.discussions.microsoft.com> wrote in message
news:37D533A5-479A-48E6-A12A-7CF2E83883FB@.microsoft.com...
>I have read conflicting reports that the number in the memory usage column
>under Current Processes is the number of pages and that it is the number of
>KB of allocated memory. Which one is correct? Thanks|||A couple of people had told me that, and one of them referenced this page:
http://www.microsoft.com/technet/pr...s/c03ppcsq.mspx
but more sources say it is the number of pages so I will stick with that. Th
anks.
"Jacco Schalkwijk" wrote:

> It's (8 KB) pages. See the documentation for sysprocesses (from which the
> information in Enterprise Manager is derived) in BOL.
> Where did you read the information that it was KB instead of pages btw?
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "J Jetson" <JJetson@.discussions.microsoft.com> wrote in message
> news:37D533A5-479A-48E6-A12A-7CF2E83883FB@.microsoft.com...
>
>