ST-PI, ST/A-PI, SPAM and SAINT upgrade #en, #whatIlearned, #work

Sometimes the most basic things are the most important and easy to forget.
So when you need to do ST-PI or ST/A-PI upgrade ... its good to use little choice in upper menu :

Support package -> Import SPAM/SAINT Update
- then restart SPAM / SAINT

Its not written in SAP note when you are upgrading ST-PI or API .. because it's so easy, they suppose you know it.

Rest of process is in notes:
Note 539977   - ST-PI Support Packages

own functions in Oracle DB #en, #whatIlearned, #work

Sometimes you are allowed or even forced to use functions in Oracle table field. I stumble on this when I was in need to check validity of security check we had.

In this case I was in need to validate if passwords are correctly checked for given profile. One parameter of "PROFILE" objects is "PASSWORD_VERIFY_FUNCTION". By default, there is function given to you by Oracle, but you could change it (perhaps to "my_function").

To do this, there is function to create your own function (CREATE OR REPLACE FUNCTION function ...). 
But when you forgot source code of it, you could see it in this way.

SELECT text FROM user_source WHERE name='<function_name>';

Easy and simple. For any function.
And that's all for today.

IDs of SAP in Oracle DB #whatIlearned #work

During my search for proper scheme and ID I found out interesting document which is summarizing ID created by Oracle and SAP during initial system installation.

Interesting is, that nearly half of them is not used in my work *grin*.

IDs used by SAP are:
SAPR3 / SAP<sid> / SAP<xyz> / SAPSR3 
- owner of all R/3 object
SAPR3SHD / SAP<sid>SHD / SAP<xyz>SHD / SAPSR3SHD 
- not required in BAU (only for SAP shadow upgrade)
SYSTEM 
- used and is pretty powerful (and owner of some objects)
SYS  
- powerful owner of most system tablespaces 
OPS$<sid>ADM (NT, UNIX) / OPS$SAPSERVICE<sid> (NT) 
- for BRTOOLS and used by R/3 itself
OUTLN 
- Stored Outlines are managed in the OUTLN user.
SAP<sid>DB / SAP<xyz>DB / SAPSR3DB
- for J2EE environment as of Release 6.30

SAPPCD
- for EP environment.
SAPWCM
- for EP environment.

TSMSYS
- no use in R/3 environment.
DBSNMP
- no use in R/3 environment.
DIP
- no use in R/3 environment.
CTXSYS
- no use in R/3 environment (except for Requisite/BugsEye)

INTERNAL
- no more available (from 9.0).

There is link to original and very interesting document:
 http://kmit4u.blogspot.cz/2010/09/sap-basis-sap-env-for-oracle-schemapriv.html

Oracle DB and OS users authorized in to it #whatIlearned #en

Still little messy for me ... but I hope I get it right (we had argument with my colleague about this even after reading page in reference)

When you need to check what users from your OS can access Oracle DB, you should first go to Oracle and submit command:

SHOW PARAMETER os_authent_prefix

you will find prefix for users OS authorized to DB, then you can list all users in your DB. Any user with this prefix is OS user with rights to access DB.

If you wanted know more, there is nice page:
http://www.oracle-base.com/articles/misc/os-authentication.php

chown command ... is not chmod by way of working with #en #whatIlearned

Did you know that you usually cannot use chown command if you are not root? This command is theoretically possible to be used by other users, but even then, it's little tricky.

You can use chomod command on any file, only if you are owner (or if you are in group? I need to check this), but you can chown only on file you are not owner and wanted to take it.
It's not possible to push ownership of file to any other person, only to take it for yourself (if you have write rights to it). But anyway for AIX you need root to use this command.So either sudo to root or modify sudo command list for your users or yourself.

Maybe now I will use that command more properly ... and even when I'm not switched to root.