Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Recent Posts

Tuesday, December 20, 2011

SAP note 830576 - PGA_AGGREGATE_TARGET on Oracle 10gR2

SAP note 830576 "Parameter Recommendations for Oracle 10g" is quite a popular one for me.
It lists all the SAP recommended Oracle 10g parameter settings for Oracle 10.2.0.4 and 10.2.0.5.
It's a good point of reference and I'd recommend you implement it as a baseline before tuning the system further.
It has a buddy note, 1289199 "Information About Oracle Parameters" which describes some of the parameters in more detail.

Unfortunately, there is a major flaw on note 830576.  When setting PGA_AGGREGATE_TARGET the SAP note says 20% of available memory.  It fails to mention that this should be 20% of the SGA size, not O/S memory.
The Oracle docs (see MYOS note 153367.1) say that the value should be:

Syntax                PGA_AGGREGATE_TARGET = integer [K | M | G]
Default value      10 MB or 20% of the size of the SGA, whichever is greater
Modifiable         ALTER SYSTEM
Range of values Minimum: 10 MB
                         Maximum: 4096 GB - 1

The Oracle note goes on to say that when sizing the Oracle database memory areas, you should consider the SGA size first, then assign any spare memory to PGA.
Now in an SAP landscape with a single Central Instance + Dialog Instance on the same server as the database, you may wish to use the SAP 70/30 rule (70% to SAP, 30% to Oracle).

My order of sizing would look something like this:
1, Determine number of users of SAP system.
2, Determine number of DIALOG work processes + Background work processes + Update processes (~= Oracle "processes").
3, Determine leftover memory for Oracle SGA (split between pools, SAP doesn't support automatic memory management).
4, Determine leftover memory for PGA + overheads.

If you get to step 4 and you have diddly squat RAM left (hardly any), then consider adding more RAM to your server.  Remember, we don't like pageing.

SAP note 789011 "FAQ: Oracle Memory Areas", provides a range of SQL statements for checking the actual size of the PGA.  Since PGA_AGGREGATE_TARGET is only telling Oracle what you would like the maximum PGA allocation to be.

When you set PGA_AGGREGATE_TARGET, you also allow Oracle to release PGA memory back to the O/S.  Using the *_AREA_SIZE parameters and setting PGA_AGGREGATE_TARGET to 0, forces a specific size of PGA which does not release the memory to the O/S.

/* Actual PGA consumption */
SELECT VALUE FROM V$PGASTAT WHERE NAME = 'total PGA allocated';

/* Chronological PGA allocation (needs AWR license) */
SELECT SUBSTR(S.END_INTERVAL_TIME, 1, 40) TIME,
               P.VALUE PGA_ALLOCATION
  FROM DBA_HIST_SNAPSHOT S, DBA_HIST_PGASTAT P
WHERE P.NAME = 'total PGA allocated'
    AND S.SNAP_ID = P.SNAP_ID
ORDER BY P.SNAP_ID;


Oracle states:
Memory Area                                                             Dedicated Server     Shared Server
Nature of session memory                                                     Private           Shared
Location of the persistent area                                               PGA              SGA
Location of part of the runtime area for SELECT statements  PGA              PGA
Location of the runtime area for DML/DDL statements          PGA              PGA

When installing Oracle for SAP, by default it uses DEDICATED server mode (see note 70197).

Thursday, December 15, 2011

SAP Sender Address for Communication Method

Whilst configuring SAP to send email oubound via SMTP you have to configure the node in SCOT to point to an SMTP server.
Once this is done, you would expect it to just work.
Unfortunatly, you may get the following issue.

When you create a new email message in SO01, you enter the recpient and the message text, then click send, and you are prompted with an error:




The error in the log book says:

"You do not have a sender address in the chosen communication method."

This was an odd error, but a quick search on SAP notes revealed note 552616.

https://service.sap.com/sap/support/notes/552616

The note mentioned either setting my user's external email address in SU3 (or SU01), or alternatively, instead of doing this for all users that wish to send external mail, you can set the "default domain" in SCOT.



Set the default domain to something like "mydomain.com".
This means SAP will create an outbound sender address comprised of the SAP username plus the default domain (sapuser@mydomain.com).

I was then able to send mail externally.

Tuesday, December 13, 2011

Oracle on NetApp via NFS (yes, really, NFS!)

I've blogged about SAP on HP-UX before, which includes a load of notes and whitepapers about Oracle on HP-UX.
This blog post is about Oracle storage on NetApp.

Here's a NetApp whitepaper specifically for Oracle on HP-UX, when using NFS mounted partitions from a NetApp device.
You should pay particular attention to ensuring that you have the correct OS patches applied, plus the kernel settings related to NFS should be set.  You should also note the section on direct I/O.

This is the HP whitepaper for NFS tuneables but it's been moved into the new HP site.  It looks like it's possible to get a slightly older version for HP-UX 11iv2 from ManualShark.org here.

I'm currently seeing average Oracle sequential read times of about 5-8ms running over a single gigabit ethernet card.

If at all possible ensure that you test the new architecture before hand (TEST should be representative of PRD!).
Make sure you identify and reduce Oracle full tablescans if possible.  Basically reduce I/O as much as possible.
Be prepared to bump up the buffer cache a little if you have the RAM (or the slots for the RAM).

Ensure that your Oracle partitions are seperate partitions and not shared with any other apps, so that you can change the mount point options specifically for Oracle.
Set the Oracle partitions file system block sizes according to Oracle/HP-UX best practice (again, see my other SAP on HP-UX post for more on this).

Most importantly, have your DB tuning team on standby, get those AWR snapshots running more frequently and make use of the ASH reports specifically for tuning SQL statements.

Tuesday, December 06, 2011

Monday, December 05, 2011

Transporting SAP User Groups

I've blogged about SAP user groups before: http://darrylgriffiths.blogspot.com/2011/09/sap-user-groups.html
Let's say you've set them up in your DEV system and now you're expecing to just transport them.  Well, as with all things SAP, it's never quite that easy.

Create a new workbench transport request in SE01, SE09 or SE10 (doesn’t matter which).
Then open the request at the request level by double clicking it.
Switch to change mode by clicking the pencil button:



Now manually type in the program Id, object type and object names as follows:

R3TR TABU USGRP
R3TR TABU USGRPT



Click Yes at the prompt:



On each item, click the Function button (key symbol):



Enter * in the Table Keys field:



Save the request again.

That's it!

Release the transport and import into the next system.
This is a farily generic process that can b used to transport any table values.
NOTE: You should be aware that the "*" in the table key, means all items specific to the current client.

Saturday, December 03, 2011

Android 2.1 Calendar Sync Force Close


I have an Android 2.1 phone (an Acer Liquid A1) which recently started throwing an error during the calendar sync.  It kept showing a "force close" error.

I got my laptop setup to connect to the phone using the Acer Liquid Tool (USB drivers) and the Malez recovery software, which includes the ADB debugging software.
After connecting the phone via USB and running ADB logcat, I was able to get the following error from the phone when I sync'd the calendar:

W/dalvikvm(  823): threadid=15: thread exiting with uncaught exception (group=0x2aac6160)
E/AndroidRuntime(  823): Uncaught handler: thread SyncThread exiting due to uncaught exception
E/AndroidRuntime(  823): java.lang.NullPointerException
E/AndroidRuntime(  823):        at com.android.providers.calendar.CalendarSyncAdapter.fetchCalendarsFromServer(CalendarSyncAdapter.java:1622)
E/AndroidRuntime(  823):        at com.android.providers.calendar.CalendarSyncAdapter.getServerDiffs(CalendarSyncAdapter.java:1223)
E/AndroidRuntime(  823):        at android.content.TempProviderSyncAdapter$SyncThread.runSyncLoop(TempProviderSyncAdapter.java:367)
E/AndroidRuntime(  823):        at android.content.TempProviderSyncAdapter$SyncThread.sync(TempProviderSyncAdapter.java:287)
E/AndroidRuntime(  823):        at android.content.TempProviderSyncAdapter$SyncThread.run(TempProviderSyncAdapter.java:218)


After an awful lot of Googling, I still had no answer.
It looks like the 2.1 version of Android supplied by Acer, has a flaw that prevents it working properly with some new Google calendar feature.
I don't know what the problem is.
Instead, to solve the problem, I flashed the ROM back to stock Acer Android 1.6.
The calendar then worked again properly, however, I had lost an awful lot of good functionality (Facebook integration, better Gmail & Android Market app versions etc etc).

So I tried another option.  I used a link on the Modaco forums for a hacked version of the Android 2.2 OS which was for the new Acer LiquidE (same phone hardware, but with 512MB of RAM instead of 256MB).
Someone has posted a version which had been enabled to run on my 256MB Acer Liquid (genius).

I flashed the 2.2 ROM onto the phone and the calendar now works again.

Despite the problem, this highlighted an area of short sightedness.  When/if the online Google apps are no longer supported or work on older Android versions, this will make the phones that use the older Android versions effectively worthless.  Who wants an Android phone with no cloud capability?

What's in a SAP EHP Anyway...

For some time I've often wondered how you can determine what functionality exists in an Enhancement Package (EHP).
I've supported SAP ERP 6.00 systems for a while, but I've never been involved in the business functionality decisions (I'm a technical guy and this is a Solution Architect's job).
So it made me wonder, if you were implementing a brand new SAP ERP 6.00 system, how would you determine what level of EHP was right for you.
Well the answer is simple, once I'd done a little reading.

All SAP EHPs are cumulative.  i.e. SAP ERP 6.00 EHP 5 includes all the new features included in EHPs 1 to 4, plus some shiny new ones.
So you see, you just need to implement the latest and greatest to get "everything", then switch it on if you want it.  You can use the new SAP BFP (Business Function Prediction) to see what's in each EHP.

So, why do SAP continue to dish out the older EHPs?  or even the base ERP 6.0 release?
Well that is down to software release management and the way that SAP develop the code.
Each EHP is effectively a branch off the main code-set.  Each of these branches will need patches, so SAP can't just kill off EHP 4 when EHP 5 is out.  They must maintain the support.
For this reason, you will see why the Support Package Stack (SP-Stack) schedule always has the latest sp-stack for the base release out before the first EHP, before the second and so on.

Like this:
ERP 6.0
              \-> ERP 6.0 EHP 1
                                            \-> ERP 6.0 EHP 2

                                                                          \-> ERP 6.0 EHP 3 ....

The release schedule simply follows the way the support packages are tested and released up through the code-set branches.



The time difference between the base release sp-stack and an EHP sp-stack could be a good indication of the amount of change between the base release and an EHP.

So is there a technical reason why you wouldn't implement the latest and greatest EHP (as recommended by SAP)?



My answer is YES.  I don't buy a car with everything included, because I know that I can get a SATNAV cheaper elsewhere.  Now I guess this depends on your software strategy.
Plus, the more tech you have, the more that could go wrong during application of support patches and upgrades.  Lastly, even if you're not using the EHP functionality, you still have to apply the code during the patch process, increasing upgrade time.

I maintain, if you don't need it or want it, why apply it.
This is obviously my view, and the counter argument would be that you have the option of "just in time" enabling of new business functionality.  In my experience, even the decisions take longer than the actual implementation time, even without "just in time".