Install PIT into existent user WITHOUT need for DBA privileges about pit HOT 3 CLOSED

Hi Sam, all your suggestions are correct. I don’t need ANY privileges (and I don’t grant them, or did you see me doing this anywhere? That would be a bug then.). It is very much possible to let others create the global context, I did that at a client. This context is created at core/scripts/create_global_context.sql. What I need is a select grant on dba_context. I use this to make sure that the context referenced is globally accessible. If you don’t want to check that, you would have to remove that check from utl_context package in line 139 ff. I maybe do this with a dynamic cursor to be able to catch an error and don’t test in this case in a alter release. Beste regards, Jürgen

Hi Sam, thank you for your interest in PIT and I agree, it’s awesome … ;-) Installing requies a DBA armed user not only because of convenience but because it must be possible to grant certain privileges to the user owing PIT. Most of them are very common but there are others that require somewhat more specific approaches: PIT stores the actual logging status in a context that is accessible across session borders. This allows for logging in a connection pool environment, where a user spreads it’s calls to the dataabase amongst several sessions. Creating a globally accessible context is sometimes restricted in normal environments. Another slightly more special grant is a direct grant to create procedures. It’s not sufficient to have that grant as part of a role, as PIT_ADMIN will dynamically create a package called MSG containing constants and exception declaraiions for all messages of severity 20 or 30 (fatal or normal error). Without this privilege, PIT_ADMIN won’t be able to create this package. An alternative would be to compile PIT_ADMIN with current_user privileges. Whether this is acceptable for you is hard to tell from my side. PIT allows for an unlimited amount of output modules writing to whatever data sink you like, mail, tables, flat files, the console or APEX just to name a few. Depending on which output modules you require, additional grants must be given. A list of required privileges is given in file set_grants.sql on the topmost level of the install. All grants that are required can be seen in the respective module folder under scripts. So, for module pit_mail, it checks whether grants to url_smtp, url_tcp and utl_encode exist. A possible alternative to install it using an administrator account would be: - Either ask the database team to install PIT for you - Assure that the required grants exist and rewrite the log on script to connect to the target user without sysdba privileges Another problem occurs if you want to publish PIT to other users. Normal installation would be to install PIT into a Utilities user and grant access to other schemas as required. There is a script to achieve that, but it on hand hand grants the respective execute grants and on the other hand creates synonyms on the grantee side. Therefore the installation script must be rewritten to split that up into two scripts and run them under the respective user. Best regards, Jürgen