Solution to ORA-12519 errors

After the system runs normally for one month, the following error occurs on the first day of the launch. After a long time, you have no idea.

Java. SQL. SQLException: Io exception: Connection refused (DESCRIPTION = (TMP =) (VSNNUM = 169869568) (ERR = 12519) (ERROR_STACK = (ERROR = (CODE = 12519) (EMFI = 4 ))))

Later find the database listening exception, found that ORA-12519 rejection error. Later, it was discovered that the connection pool of data reached its extreme.

The specific solution is as follows:

-- Check the usage of process and session in sqlplus.

SQL> show parameter processes

NAME TYPE VALUE
-----------------------------------------------------------------------------
Aq_tm_processes integer 0
Db_writer_processes integer 6
Gcs_server_processes integer 0
Job_queue_processes integer 0
Log_archive_max_processes integer 2
Processes integer 150
 

SQL> select count (*) from v $ process;

COUNT (*)
----------
147
-- Obviously, process has almost reached its peak.

SQL> show parameter session

NAME TYPE VALUE
-----------------------------------------------------------------------------
Java_max_sessionspace_size integer 0
Java_soft_sessionspace_limit integer 0
License_max_sessions integer 0
License_sessions_warning integer 0
Logmnr_max_persistent_sessions integer 1
Session_cached_cursors integer 20
Session_max_open_files integer 10
Sessions integer 160

Shared_server_sessions integer
SQL>
 

SQL> select count (*) from v $ session;

COUNT (*)
----------
153

-- Almost reached its peak.

-- Modify the process and session values of Oracle to increase their maximum number of connections.

-- The oracle document requires that the initialization parameters of SESSIONS and TRANSACTIONS should be derived from the PROCESSES parameter. According to the default setting of SESSIONS = PROCESSES * 1.1 + 5

SQL> alter system set processes = 300 scope = spfile;

System altered.

SQL> alter system set sessions = 335 scope = spfile;

System altered.

-- After the database is restarted, the parameter modification is complete.

SQL> shutdown -- if the connection request is not closed after a long time, you can use the abort parameter to directly close the connection request.

SQL> startup -- you can use the force parameter to close the currently running database and start it normally.

After modification, the problem is solved during the stress test.