UDA-SOR-0001 Unable to Allocate Memory

[karthik.cognos]

Hi,
I have developed a report in report studio (version: 10.1.1) and it runs against a Teradata database (version: 13.10) and it has 17 cross tabs & 15 charts. Recently while I was nearing to complete the report development I started running into this error: UDA-SOR-0001 Unable to allocate memory.

I goggled the error and found out that I might be running out of sort buffer memory when I run the report for 2 year time frame (2 year time frame is the business requirement and sort buffer set to 16MB in our environment).

When I contacted my Cognos Admin they said we have 32 bit servers and 64 bit servers in our environment and they said they will set up a rule to have this report executed on a 64 bit server but even that did not help.

The report has to run in Excel 2007 format.

Could you guys please shed some light to solve this problem?

Thanks in Advance for your help!

KC

[dd926g]

I've experienced the same issue. We bumped up memory in Cognos Config to 240mb, report exported to excel 2007 in Dev but not in Prod. Im thinking that was because of a larger dataset in Prod. I'm having similar issues with a report that I do not need to export to Excel and again its a large report with over 20 queries. I get the "Failure   RSV-SRV-0063 An error occurred while executing the 'asynchRun_Request' command. Out of memory   " error.

I'm thinking about installing an additional dispatcher on the Prod server and creating routing rule to have it hit a dedicated dispatcher.

Does anyone think this could help resolve error?

[the6campbells]

The BiBusTKServerMain process is running out of memory.

Unless you are using Dynamic Query, you cannot use 64-Bit Report Servers.

A 32-bit ReportServer will be bounded by the amount of memory the O/S will allow it to address. For example, on 64-bit Windows the O/S will let it grow ~3GB while 32-Bit Windows was more around ~1.8.

If you are on Windows and watch the Private bytes of the process with a new BiBusTkServerMain as you test your report, you can quickly see how much your report is trying to eat up. Reports which many page layouts and objects potentially will push the memory usage to the point of failing.

Now, for persons using Postgres (i.e via ODBC), ensure that your DSN is configured to direct Postgres to NOT cache any result set in it's buffer space. It presumes to cache any result set irrespective of size  and can quickly eat resources to the point of failure.

Do not jack up sort buffer spaces, the actual memory usage is (2* buffer size) * # of concurrent sorts. Hence, anyone who advocates jacking it up is passing out bad advice. If you have a report design with many page specifications and many layouts and you have been trying to use Report Servers concurrent query feature, turn that off for this report.

Now, you might have memory leaks in the product etc. hence you may have to open a support call with IBM for it be to be reviewed more closely.