Due to beyond the problem of maximum number of processes, ora - 00020 changed the processes 1500
After the database is normal, but the recent discovery in udump almost all of the TRC file, there are five or six ORA - 00020 error, and there is an error in the alert file, database and looked at normal, just seems to be feeling a little slower, please have a look at what reason be?

ORA - 00020: maximum number of the processes exceeded 150
/export/home/oracle/admin/former/udump/orcl_ora_21259 TRC
Oracle Database 10 g Enterprise Edition Release 10.2.0.4.0-64 - bit Production
With the Partitioning, OLAP, Data Mining, and Real Application Testing options
ORACLE_HOME=/export/home/oracle/product/10.0
The System name: SunOS
The Node name: EEE - DataBase
Release: 5.10
Version: Generic_148888-01
Machine: sun4v
The Instance name: former
Redo thread mounted by this instance: 1
Oracle process number: 0
Unix process pid: 21259, image: oracle @ EEE - DataBase


SQL> Show the parameter process;

The NAME, TYPE, VALUE
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Aq_tm_processes integer 0
Db_writer_processes integer 16
Gcs_server_processes integer 0
Job_queue_processes integer 10
Log_archive_max_processes integer 2
The processes of integer 1500

SQL> Select count (*) from v $process;
COUNT (*)
-- -- -- -- -- -- -- -- -- --
256

CodePudding user response:

How do you feel there is something wrong with the

CodePudding user response:

Should still have problems, but do not know how to start

CodePudding user response:

refer to the second floor dz0077 response:

should still have problems, but do not know how to start the

Has a person, have no disease, he went to the doctor to see a doctor, the doctor said he wasn't sick, but he said he was sick, what then?
A, the doctor drove him out;
B, the doctor drove it out of him, he turned to stabbing the doctor
C, he has been feeling sick, but all the doctors said he wasn't sick, and then one day he was mad, really sick...



Okay, seriously:
You said you feel database slow? Where is the slow? Slow at some function point? Or all operations? Very many slow? Such as the original ran 100 ms SQL, ran the 200 milliseconds now? Looking at normal database? Why do you think he is normal? Feel it normal? Then feel it is a little slow?
1, if you think the libraries are slow, then provide: what do you think of database slow time who runs AWR reports;
2, if you feel a certain function point slowly, then find out the function point run slow SQL, provide the SQL execution plan,
At least with these information and then ask the first performance problems, although the above is a joke, but one thing is similar with doctors: the problem is not guess, feelings, fall in love when the problem is probably so to , but needs to be checked, according to the need to have with,

BTW: process for this kind of thing, even if really related problems, it also can only be number representation, such as process burst, is not the root of the problem,

CodePudding user response:

To tell the truth, sense data can be found that is not normal without downtime, see the alert file, not just a fatal mistake, is new for the database server, CPU and memory is better than the original one times, but the user reflect slower than before,
The alert file:
Fri Nov 17 15:04:16 2017
Thread 1 advanced to log sequence 17463 (LGWR switch)
Current log# 9 seq# mem# 0:17463/oradata/former/redo09 log
Fri Nov 17 15:09:46 2017
Thread 1 advanced to log sequence 17464 (LGWR switch)
Current log# 10 seq# mem# 0:17464/oradata/former/redo10 log
Fri Nov 17 15:16:54 2017
Thread 1 advanced to log sequence 17465 (LGWR switch)
Current log# seq# 17465 mem# 0:1/oradata/former/redo01 log
Fri Nov 17 15:19:11 2017
Thread 1 advanced to log sequence 17466 (LGWR switch)
Current log# 2 seq# mem# 0:17466/oradata/former/redo02 log
Fri Nov 17 15:19:29 2017
Thread 1 advanced to log sequence 17467 (LGWR switch)
Current log# seq# 17467 mem# 0:3/oradata/former/redo03 log
Fri Nov 17 15:19:52 2017
Thread 1 advanced to log sequence 17468 (LGWR switch)
Current log# 4 seq# mem# 0:17468/oradata/former/redo04 log
Fri Nov 17 15:20:39 2017
Thread 1 advanced to log sequence 17469 (LGWR switch)
Current log# 5 seq# 17469 mem# 0:/oradata/former/redo05 log
Fri Nov 17 15:22:36 2017
ORA - 00060: Deadlock detected. More info in the file/export/home/oracle/admin/former/udump/former
_ora_25025. TRC.
Fri Nov 17 15:25:18 2017
Thread 1 advanced to log sequence 17470 (LGWR switch)
Current log# 11 seq# mem# 0:17470/oradata/former/redo11 log
Fri Nov 17 15:31:22 2017
Thread 1 advanced to log sequence 17471 (LGWR switch)
Current log# 12 seq# mem# 0:17471/oradata/former/redo12 log
Fri Nov 17 15:38:24 2017
Thread 1 advanced to log sequence 17472 (LGWR switch)
Current log# 6 seq# mem# 0:17472/oradata/former/redo06 log
Fri Nov 17 15:47:12 2017
Thread 1 advanced to log sequence 17473 (LGWR switch)
Current log# 7 seq# mem# 0:17473/oradata/former/redo07 log
Fri Nov 17 15:52:40 2017
Thread 1 advanced to log sequence 17474 (LGWR switch)
Current log# 8 seq# mem# 0:17474/oradata/former/redo08 log
Fri Nov 17 15:54:17 2017
ORA - 00060: Deadlock detected. More info in the file/export/home/oracle/admin/former/udump/former
_ora_7809. TRC.
Fri Nov 17 15:57:15 2017
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull