recommendations for userva option in Windows 2003

[mathias_dieckhoff]

Hello,

we are running ERP2005 on Windows 2003 32Bit and Oracle 10.2.

We activated the /3GB option in the boot.ini

Due to problems we wan't to activate the userva option.

Unfortunalely i can't find any recommendation for the value of userva.

Please give me an advice.

Kind regards

Mathias Dieckhoff

[former_member204746 · Accepted solution]

have you read http://support.microsoft.com/kb/316739 ?

note that using Netweaver 2004s SAP products, you should be on a 64-bit platform for productive support.

[mathias_dieckhoff · Accepted solution]

Hello Eric,

thaaks for your advice.

i made a mistake. we are running ERP 2004. sorry... the names change so often

i read the knowledgebase article, while searching for a solution. i hope to find a general value like this one:

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f92ae734-0d01-0010-0496-d4254eb8...

recommendation for a RAC environment: the value should be 3008 (page 12)

Is this also valid for non-RAC?

regards

Mathias Dieckhoff

[Former Member · Accepted solution]

Matthias,

please follow my suggestions.

There is no general rule we can give here. The optimum value of /userva depends on so many parameters, the major ones we have identified is number of tcp/connections, number of open files, amount of memory addressed by all workprocesses (not necessary in the working set) etc.

Peter

[mathias_dieckhoff · Accepted solution]

Hi Peter,

is it useful to start with a value near the 3072 MB e.g. 3008 or the other way around?

regards

Mathias

[Former Member · Accepted solution]

3072 MB is the value when /userva is not set.

I would recommend to start with /userva = 2900 and decrease this value by 100 until you do not have resource problems any longer.

But your are also free to start with 3050 and decrease it 50 wise.

Peter

[mathias_dieckhoff · Accepted solution]

Thanks for your help Peter.

I will try it out.

Regards

Mathias

[Former Member]

Hello Mathias,

This parameter was recommended with different values from different sources. For example, 3008 from the Best Practice published by Oracle.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f92ae734-0d01-0010-0496-d4254eb8...

Meanwhile I cannot agree with Eric more that you should consider 64-bit Windows.

Best regards,

Victor

[Former Member]

>>For example, 3008 from the

that's a recommendation for Oracle RAC specific configurations (less then 10 installations world wide) forget this value.

>>Meanwhile I cannot agree with Eric more that you should consider 64-bit Windows.

why that?

I am very interested in the arguments againts 64 Bit, please post them here!!

[Former Member]

Hi Peter,

I used that document as an example. There are more userva values suggested from different sources. The OSS message I opened years ago suggested something like 2700. Basically my point is "there is no magic number for this parameter, try and est it, or better go to 64-bit".

I think you misunderstood me... "Cannot agree with something more" means "fully agree with something (so you cannot agree More)".

Best regards,

Victor

[mathias_dieckhoff]

hi,

i know that a migration to 64bit will solve the problem.

but this is something different...

so i will try the way described in the MS article.

maybe i find a good value..

i'm still interested in recommendations for the userva parameter.

regards

Mathias Dieckhoff

[Former Member]

well it is as Eric already mentioned:

1st recommendation: Go for 64 Bit!

2nd recommendation:

decrease the user address space carefully if you have to.

start with /userva=2900, if the problem still happens change /userva step by step to lower values each time evaluating wether the new value has fixed the situation.

the problem with /userva is, that it shortens the virtual address space (addressable memory for normal applications). with /userva=2700 your application is able to address 2.7 GB of virtual memory, the remaining 1.3 GB can only be used in kernel mode (operating system, drivers etc). In this case (/userva=2700) your application (ABAP Report, other memory consuming programs) can only utilize 300 MB less memory compared to /userva not set.

Those ABAP reports currently utilizing 95 percent of the available address space will no longer run when /userva is set to 2700.

It is much less pain to run on 64 Bit OS - you don't have to play around with all these funny parameters.

peter