server processesleri iki çeşittir:
- dedicated server process sadece bir user içindir. ve her kullaıcı içn bir server process oluşturulur. kullanıcılarin bir birleri ile iletişimi yoktur. bu demektir ki her kullanıcı için ayrı birer pga alanı ayrılması gerekir. buda total pga dan karşılanır. kısaca kullanıcılara ayrılan pga alanları kullanıcı sayısını bağlı olmak la birlikte küçülür. özellikte sort ve merge tarzı büyük sorgularda işlemlerin pga ya sığmayarak. diske yönelmek demektir. buda performans kaybına neden olur.
not:pga heap alanından her oracle process için ayrılmış bellek alanıdır. PGA_AGGREGATE_TARGET parametresiyle max. boyutu belirlenebilir. dedicated serverlar da pga içinda uga barındırılı. uga ise her kullanıcı için bir session state tutar.
- shared server process çoklu kullanıcılar içindir. bir dispatcher process olabilir ve hepsine sırayla cevap verir. uzun süreli işlemlerde kullanıcılar bir birini beklemek zorunda kalabilir. bu nedenle wait eventlar artabilir. dispatcher kullanımından dolayı daha az server process olur ve pga alanı artar.
Oracle Database Background Processes;
Database writer (DBWn):Database Writer işlemi, buffer cache’te bulunan değişmiş blockları diskte bulunan dosyalara yazmaktadır. Oracle en fazla 20 adet database writer işlemine izin vermektedir. parametresi: DB_WRITER_PROCESSES process sayısı belirtilir.
Log writer (LGWR):Log writer işlemi, redo log kayıtlarını diske yazmaktadır. Redo log kayıtları ilk önce SGA’da (System Global Area) bulunan redo log buffer üzerinde tutulur. Daha sonra log writer işlemi, sırasıyla bu kayıtları online redo log dosyalarına kaydeder.
Checkpoint (CKPT):Belirli zamanlarda, SGA’da bulunan database buffer verilerinin tamamı database writer işlemi tarafından disklerdeki datafile’lara yazılır. Bu olaya checkpoint denmektedir. Checkpoint işlemi, database writer işlemini tetikleyerek datafile’ların güncellenmesinden ve control file’ların en son checkpoint numarasını gösterecek şekilde düzenlenmesinden sorumludur.
System monitor (SMON):System Monitor işlemi çakılmış bir veritabanı instance’ının doğru bir şekilde açılmasından sorumludur.
Process monitor (PMON):Process monitor, kullanıcı işlemlerini takip eder ve çakılmış olanları kurtarır. Çakılmış işlem tarafından işgal edilmiş memory kaynaklarını temizleyerek kullanılabilir alan oluşturur.
Archiver (ARCn):Veritabanı, archive log mode’da iken çalışır. Bu işlem ile log switch gerçekleştiğinde ya da redo log dosyaları dolduğunda arşiv olarak kopyalamakla yükümlüdür.
Recoverer (RECO):Geri kurtarıcı dağıtık veritabanında sistem veya ağ hatalarından dolayı bekleyen işlemleri düzenler. Belli aralıklarla, yerel RECO uzaktaki veritabanına bağlanıp yereldeki dağıtık işlemlerle ilgili "commit" ve "rollback" işlemlerini yapmaktadır.
Dispatcher (Dnnn):Dispatcher lar çoklu ortamlarda isteğe bağlı olarak çalıştırılmaktadırlar. Her iletişim protokolü için en az bir dispatcher işlemi (D000,....,Dnnn) oluşturulmaktadır. Her dispatcher işlemi kullanıcı işlemlerinden gelen istekleri sunucu işlemlerine yönlendirmekte ve gelen cevapları da uygun kullanıcılara tekrar döndürmekten sorumludur.
Global Cache Service (LMS):RAC ortamında veritabanı örnekleri arasındaki kilitleme mekanizması için kullanılır.
Kilit(Lock-LCKO)
Kilit işlemleri birden fazla veritabanı oturumunun çalıştığı sistemlerde veritabanları arasında gereken bir takım kilitleme işlemlerini gerçekleştirir.
İş Kuyruğu(Job Queue-SNPn)
Dağıtık veri tabanı uygulamalarında 38 adetten fazla (SNP0,...,SNP9,SNPA,....SNPZ) iş kuyruğu işlemi tablo snapshotlarını otomatik olarak güncelleyebilir. Bu işlemler periyodik olarak başlatılır
Kuyruk Monitörü (QMNn) : Oracle Advanced Queuing opsiyonuna ait olan mesaj kuyruklarını izlemesi için yaratılan opsiyonel işlemlerdir. En çok on adet kuyruk mönitörü işlemi tanımlanabilir.
Parallel Execution
Oracle Database Enterprise Edition ile gelen bir özelliktir. oracle in bir tek process ile yapacağı işi bir den çok küçük parçaçıklara ayırarak çalışmasıdır.
Parallel Execution uygulamadan önce iki şeyden emin olmalısınız.
1-) Büyük bir taskınız olmalı (Mesela 50 gb full scan data)
2-) Yeterli kaynağınız oldugundan emin olmalısınız yeterli cpu ve I/O gibi (Paralel Processlerin çalışması için).50 gb verininde bieden çok diske dagılması ve disklerden datayı getirmek için I/O kanallarının yeterli olması beklenir.
PARALLEL_MAX_SERVERS >0 olmalı
Paralel Query
alter table table_name paralel ;
ALTER SESSION DISABLE||ENABLE PARALLEL DDL;
ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;
V$PQ_SESSTAT
SELECT * FROM v$pq_sesstat;
Unix de |ps -ef|grep "ora_p"
select
statistic,
value
from
v$pq_sysstat
where
statistic = 'Servers Busy';
Slave processlerin hangi sql li çalıştırdığını da viewleri joinleyerek bakabiliriz. Burda processler aktif olmak zorundadır.
select p.server_name,
sql.sql_text
from v$px_process p, v$sql sql, v$session s
WHERE p.sid = s.sid
and p.serial# = s.serial#
and s.sql_address = sql.address
and s.sql_hash_value = sql.hash_value
• Parallel execution kullanmadan once araştırmalı eger imkan varsa initial testler yapılmalıdır aksi halde büyük problemlerle karşılaşabilinir.
• Parallel Execution donanımı en yoğun kullanmak için tasarlanmıştır. Tek cpu, iki 512 MB lik disk le çok büyük performans artışı beklemek yanlış olacaktır.
• Parallel Execution kullanırken once sql tune edin edin kötü yazılmış ve tasarlanmış uygulamaya parallel execution uygulamaya kalkmayın.
• Kısa süren transactionlarda PX kullanmanız çok az iyileşmeye hatta daha yavaş çalışmaya mahkum olabilir. Kısa sorgu için tüm kaynakları kullanmış olursunuz.
• Parallel Executions geceyarıları batch operasyonları için ya da multiple streams joblarında genelde performans gösterir ama yine de bu uygulamanın türüne bağlıdır.
• Create as Select ya da büyük bulk insert into parallel olarak gerçekleştiriliyorsa NOLOGING modunda çalışırsa performans artar çünkü redo log’a yazdıgınız herşey extra I/O dur aslında ama recovery durumunda logları manuel olarak oluşturmanız gerekecektir.
• PARALLEL_AUTOMATIC_TUNING parametresini true yapın
External Procedure
Harici yordamların kullanılabilmesi için Ağ Yönetiminde gerekli ayarların yapılması gerekmektedir.
The environment for calling external procedures, consisting of tnsnames.ora and listener.ora entries, is configured by default during the installation of your database.
Terminating Sessions
ALTER SYSTEM KILL SESSION '7,15';
SELECT SID, SERIAL#, STATUS
FROM V$SESSION
WHERE USERNAME = '$username'
active session kill hataları;
ORA-00028: your session has been killed
ORA-01012: not logged on
Monitoring the Operation of Your Database
To retrieve threshold values, use the GET_THRESHOLD procedure. For example:
DECLARE
warning_operator BINARY_INTEGER;
warning_value VARCHAR2(60);
critical_operator BINARY_INTEGER;
critical_value VARCHAR2(60);
observation_period BINARY_INTEGER;
consecutive_occurrences BINARY_INTEGER;
BEGIN
DBMS_SERVER_ALERT.GET_THRESHOLD(
DBMS_SERVER_ALERT.CPU_TIME_PER_CALL, warning_operator, warning_value,
critical_operator, critical_value, observation_period,
consecutive_occurrences, 'inst1',
DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'main.regress.rdbms.dev.us.oracle.com');
DBMS_OUTPUT.PUT_LINE('Warning operator: ' || warning_operator);
DBMS_OUTPUT.PUT_LINE('Warning value: ' || warning_value);
DBMS_OUTPUT.PUT_LINE('Critical operator: ' || critical_operator);
DBMS_OUTPUT.PUT_LINE('Critical value: ' || critical_value);
DBMS_OUTPUT.PUT_LINE('Observation_period: ' || observation_period);
DBMS_OUTPUT.PUT_LINE('Consecutive occurrences:' || consecutive_occurrences);
END;
/
You can also check specific threshold settings with the DBA_THRESHOLDS view. For example:
SELECT metrics_name, warning_value, critical_value, consecutive_occurrences
FROM DBA_THRESHOLDS
WHERE metrics_name LIKE '%CPU Time%';
Viewing Alert Data
The following dictionary views provide information about server alerts:
* DBA_THRESHOLDS lists the threshold settings defined for the instance.
* DBA_OUTSTANDING_ALERTS describes the outstanding alerts in the database.
* DBA_ALERT_HISTORY lists a history of alerts that have been cleared.
* V$ALERT_TYPES provides information such as group and type for each alert.
* V$METRICNAME contains the names, identifiers, and other information about the system metrics.
* V$METRIC and V$METRIC_HISTORY views contain system-level metric values in memory
Monitoring the Database Using Trace Files and the Alert File
The alert file, or alert log, is a special trace file. The alert file of a database is a chronological log of messages and errors, and includes the following items:
* All internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors (ORA-60) that occur
* Administrative operations, such as CREATE, ALTER, and DROP statements and STARTUP, SHUTDOWN, and ARCHIVELOG statements
* Messages and errors relating to the functions of shared server and dispatcher processes
* Errors occurring during the automatic refresh of a materialized view
* The values of all initialization parameters that had nondefault values at the time the database and instance start
Initialization parameters controlling the location and size of trace files are:
* BACKGROUND_DUMP_DEST
* USER_DUMP_DEST
* MAX_DUMP_FILE_SIZE
This example enables the SQL trace facility for a specific session:
ALTER SESSION SET SQL_TRACE TRUE;
Use the DBMS_SESSION or the DBMS_MONITOR package if you want to control SQL tracing for a session
SQL trace facility and using TKPROF and trcsess to interpret the generated trace
Monitoring Locks
View Description
*V$LOCK Lists the locks currently held by Oracle Database and outstanding requests for a lock or latch
*DBA_BLOCKERS Displays a session if it is holding a lock on an object for which another session is waiting
*DBA_WAITERS Displays a session if it is waiting for a locked object
*DBA_DDL_LOCKS Lists all DDL locks held in the database and all outstanding requests for a DDL lock
*DBA_DML_LOCKS Lists all DML locks held in the database and all outstanding requests for a DML lock
*DBA_LOCK Lists all locks or latches held in the database and all outstanding requests for a lock or latch
*DBA_LOCK_INTERNAL Displays a row for each lock or latch that is being held, and one row for each outstanding request for a lock or latch
Monitoring Wait Events
*V$PROCESS Contains information about the currently active processes
*V$LOCKED_OBJECT Lists all locks acquired by every transaction on the system
*V$SESSION Lists session information for each current session
*V$SESS_IO Contains I/O statistics for each user session
*V$SESSION_LONGOPS Displays the status of various operations that run for longer than 6 seconds (in absolute time). These operations currently include many backup and recovery functions, statistics gathering, and query execution. More operations are added for every Oracle Database release.
*V$SESSION_WAIT Lists the resources or events for which active sessions are waiting
*V$SYSSTAT Contains session statistics
*V$RESOURCE_LIMIT Provides information about current and maximum global resource utilization for some system resources
*V$SQLAREA Contains statistics about shared SQL area and contains one row for each SQL string. Also provides statistics about SQL statements that are in memory, parsed, and ready for execution
*V$LATCH Contains statistics for nonparent latches and summary statistics for parent latches
Hiç yorum yok:
Yorum Gönder