I don't know if Enterprise Manager 11g looks the same as Enterprise Manager Grid Control 10g, which is what I use. If it's similar, there should be a Security page, where you can manage users, roles, privileges, etc. Failing that, for sure you could use the following SQL commands:
CREATE USER xxx IDENTIFIED BY pppp DEFAULT TABLESPACE users;
GRANT CONNECT, RESOURCE TO xxx;
GRANT privilege TO xxx; -- repeat for each privilege in your step 4.
Background on ASA Timeout/Timers:
The global timeout conn is TCP virtual circuit (session) idle timer and defaults to 60 minutes. The global timeout udp is for UDP holes and defaults to 2 minutes. The global timeout xlate is for clearing up translations that linger around after a conn has timed out. The conn (TCP) timeout takes precedence over the xlate timeout. The next paragraph further explains the relationship between conn and xlate timers.
If a conn is successfully torn down via TCP teardown, the conn and xlate go with it (if dynamic xlate, static NAT and static PAT xlate's are never removed). If a conn times out, then the xlate timer is taken into account. If the xlate times out first (you set it real low) it will not take down the connection until the conn times out.
The ASA has several methods for dealing with the varying timeouts. Conn is one where the global setting can be overridden based on class-map -- this should be preferred over increasing the global setting if possible.
The other interesting feature the ASA possesses is dead connection detection -- DCD. DCD allows you to keep your [global] conn timeout at 60 minutes (the default) and when 60 minutes is reached -- the ASA man-in-the-middle spoofs null data ACKs to each endpoint as the other endpoint. Null data works to prevent the sequence numbers from incrementing. If both sides respond the connection's idle timer resets to 0 and begins again. If either side does not respond after a set number of attempts (configurable) in a given period the conn is removed and the xlate timer gains relevance as described above.
I'd recommend configuring a class-map and adding it to your policy that enables DCD. You can use an ACL or a port (others are available as well). Using the port is quick, easy, and will work well if you are certain the TCP/5633 is where the problem sits..
I have used the global_policy below but feel free to adjust as necessary.
class-map BE-CORBA_class
description Backup Exec CORBA Traffic Class
match port tcp eq 5633
policy-map global_policy
class BE-CORBA_class
-->::Choose one below::<--
set connection timeout idle 1:00:00 dcd --> for 8.2(2) and up
set connection timeout tcp 1:00:00 dcd --> for prior to 8.2(2)
service-policy global_policy global
@Comment
According to the reference guide -- "A packet can match only one class map in the policy map for each feature type."
The key phrase is in bold. A packet crossing an interface can match multiple classes inside of a policy-map, but only if those classes use different "features." If you scroll up just a tad in the aforementioned link you will see the various features listed. That whole page is a goldmine for MPF tidbits.
As you mentioned that you have a match any class-map defined and then referenced as a class inside the policy-map -- if you are performing any other TCP and UDP connection limits and timeouts changes in that policy-map class, then subsequent class-maps that match the traffic -- if set in the policy-map -- will not perform TCP and UDP connection limits and timeout changes on that packet.
If you post all the ACL's, class-map's, policy-map's, and service-policy's we can determine for certain.
Best Answer
It seems you misunderstand what the sysdba privilege is and how it is managed: The SYSDBA privilege is needed to perform some operations (create/drop/alter database, start or stop an instance, ...). When you connect to a database using this privilege, it is as if you were connected as user "sys".
Due to the fact that the SYSDBA privilege is needed to startup the instance, the control of this privilege is manage outside the database, ie in a group at the OS level. This group is named "dba" on unix server or "ora_dba" on windows boxes. All the OS user accounts that are in this group are allowed to connect to the database with the sysdba privilege, even if they don't have an account inside the database.
And as said in the documentation RMAN must be run with the sysdba privilege. Indeed, this user is allowed to drop any objects in the database without restriction but this is because RMAN should be run only by a dba not by some random users.
If you want to allow a user to export some objects you will have to do otherwise. If you use oracle 10g or newer, have a look at datapump. With datapump, a DBA can choose a folder on the server, where some users could export some objects.