15 Aralık 2011 Perşembe

Enabling ARCHIVELOG Mode

Most of the High Availability features of Oracle require you to enable ARCHIVELOG mode for your database. When you enable this mode redo logs will be archived instead of overwritten. The archivelogs are stored in a seperate place usually can backed up regularly by your standard filesystem backup system (NetBackup or whatever). Archive logs are utilized by RMAN, Data Guard, Flashback and many others.
If your going to enable archivelog mode on a real database thats important to you, I would recommend shutting down the database and doing a cold backup just in case. Keeping a "final noarchivelog mode backup" seems to be a good and excepted practice.
Enabling archive mode is simple, just connect to your database in mounted but closed mode (startup mount) and alter the database. But if you don't tune alittle you'll run into problems down the road, so lets specify some parameters too. Namely, consider LOG_ARCHIVE_DEST.
Lets start by checking the current archive mode.

SQL> SELECT LOG_MODE FROM SYS.V$DATABASE;

LOG_MODE
------------
NOARCHIVELOG
So we're in NOARCHIVELOG mode and we need to change. We can use a database alter statement, but that won't be perminant, so lets just update the pfile directly. The pfile should be in either $ORACLE_BASE/admin/SID/pfile or $ORACLE_HOME/admin/SID/pfile. I'll add the following lines to the end of the file:

############################
# Archive Log Destinations -benr(10/15/04)
############################
log_archive_dest_1='location=/u02/oradata/cuddle/archive'
log_archive_start=TRUE
Note that we're not actually required to specify the location of the log destination, but if you don't it'll end up in strange places (in my test it went to $ORACLE_HOME/dbs making a mess). You can specify as many as 10 diffrent archive log destinations by using the paramters log_archive_dest_1 through log_archive_dest_10. Remember, if you run out of space in your archive log destination the database will shut down!
Now we can startup the database in mount mode and put it in archivelog mode.

[oracle@vixen pfile]$sqlplus sys/passwd as sysdba;
SQL*Plus: Release 10.1.0.2.0 - Production on Fri Oct 15 16:00:58 2004
Copyright (c) 1982, 2004, Oracle.  All rights reserved.
Connected to an idle instance.

SQL> startup mount
ORACLE instance started.

Total System Global Area  184549376 bytes
Fixed Size                  1300928 bytes
Variable Size             157820480 bytes
Database Buffers           25165824 bytes
Redo Buffers                 262144 bytes
Database mounted.

SQL> alter database archivelog;
Database altered.

SQL> alter database open;
Database altered.
You can see here that we put the database in ARCHIVELOG mode by using the SQL statement "alter database archivelog", but Oracle won't let us do this unless the instance is mounted but not open. To make the change we shutdown the instance, and then startup the instance again but this time with the "mount" option which will mount the instance but not open it. Then we can enable ARCHIVELOG mode and open the database fully with the "alter database open" statement.
There are several system views that can provide us with information reguarding archives, such as:

V$DATABASE
Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode and whether MANUAL (archiving mode) has been specified.
V$ARCHIVED_LOG
Displays historical archived log information from the control file. If you use a recovery catalog, the RC_ARCHIVED_LOG view contains similar information.
V$ARCHIVE_DEST
Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations.
V$ARCHIVE_PROCESSES
Displays information about the state of the various archive processes for an instance.
V$BACKUP_REDOLOG
Contains information about any backups of archived logs. If you use a recovery catalog, the RC_BACKUP_REDOLOG contains similar information.
V$LOG
Displays all redo log groups for the database and indicates which need to be archived.
V$LOG_HISTORY
Contains log history information such as which logs have been archived and the SCN range for each archived log.
Using these tables we can verify that we are infact in ARCHIVELOG mode:

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

SQL> select DEST_NAME,STATUS,DESTINATION from V$ARCHIVE_DEST;
Learn more about managing archive redo logs in the Oracle Database Administrator's Guide:
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10739/archredo.htm

LOG_MINER Kurulumu, Konfigurasyonu ve Kullanımı


Log miner database’ in kurulumu ile birlikte gelen ve bir package yardımıyla create edilen bir opsiyon olarak düşünebiliriz. Yapabilirlikleri aslında kimi zaman herhangi bir geri dönüş operasyonuna kalkışmadan hızlı bir şekilde yapılmış olan bir hatayı düzeltebilmemize olanak sağlar. Log miner database seviyesinde yapılan bir takım işlemlerin geri alınabilmesi için izlenilen bir yöntemdir. Kullanımı ile ilgili olarak genelde yanlışlıkla yapıldığı düşünülen bir DML işlemini geri almak için kullanılabilir diyebiliriz.

Log miner database seviyesinde yapılan bir takım işlemlerin geri alınabilmesi için izlenilen bir yöntemdir. Kullanımı ile ilgili olarak genelde  yanlışlıkla yapıldığı düşünülen bir DML işlemini geri almak için kullanılabilir diyebiliriz.
Log Miner’ ın kurulumu ve konfigure edilmesi ;
Log Miner’ ın çalışması için  SUPPLEMENTAL_LOG_DATA_MIN değerinin database’ de açık olması gerekmektedir. Aşağıdaki gibi kontrol edebilirsiniz ;
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;


SUPPLEMENTAL_LOG_DATA_MIN
-------------------------------------
NO
Sonucun NO dönmesi durumunda aşağıdaki şekilde Alter edebiliriz ;
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.

Sonrasında log_miner’ ın ihtiyaç duyduğu nesnelerin create edilmesi için aşağıdaki dizindeki sql dosyası çalıştırılır.

SQL>@$ORACLE_HOME/rdbms/admin/dbmslm.sql
Paket yaratıldı.
Erişim Yetkisi verme başarılı.
Aşağıdaki yetkinin ilgili kullanıcıya
GRANT EXECUTE_CATALOG_ROLE TO kamil;
Grant complete.

Package kolay erişim için public synonym tanımlanabilir. (schema name’ i kullanılarak da erişilebilir.)

CREATE PUBLIC SYNONYM DBMS_LOGMNR FOR SYS.DBMS_LOGMNR;
Synonym created.
Log_miner’ ın redologları okuması için log_miner’ a tanıtılması, eklenmesi gerekmektedir. Bunun için önce loglarımıza bakalım ;
SQL> SELECT distinct member LOGFILENAME FROM V$LOGFILE;
LOGFILENAME
C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG
C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG
C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG
Log_miner package’ ina okuması için dahil etmek için;

BEGIN DBMS_LOGMNR.ADD_LOGFILE
('C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG');
DBMS_LOGMNR.ADD_LOGFILE
('C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG');
DBMS_LOGMNR.ADD_LOGFILE
('C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG');
END;
/
PL/SQL procedure successfully completed.

Bakacağı son archive’ ı görmek için ;

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);



NAME
C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_11_6O2RV9M1_.ARC
C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_12_6O2RVHG5_.ARC
Log_Miner kurulumu tamamlanmış oldu, şimdi start ediyoruz ;
BEGIN
DBMS_LOGMNR.START_LOGMNR
(options =>
dbms_logmnr.dict_from_online_catalog);
END;
/
PL/SQL procedure successfully completed.
Sonuçları Select etmek içinse  v$logmnr_contents view’ ini kullanabiliriz.
SELECT   username,
TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp,
seg_type_name,
seg_name,
table_space,
session# SID,
serial#,
operation,
sql_redo,
sql_undo,
session_info
FROM   v$logmnr_contents
Şimdi bir test yapalım, user_test adında bir userımız var, bu userla önce bir tablo create edelim, sonrasında içerisinde data insert edelim. En son olarak da yaptığımız bu işlemin yanlış olduğunu varsayıp nasıl düzeltebileceğimize bakalım.
create table log_miner_test as select * from dba_tables where rownum < 2 ;
Table created.

insert into log_miner_test select * from log_miner_test ;
1 row created.

commit
Commit complete.
v$logmnr_contents  tablosundan select ediyoruz.

SELECT   username,
         TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp,
         seg_type_name,
         seg_name,
         table_space,
         session# SID,
         serial#,
         operation,
         sql_redo,
         sql_undo,
         session_info
  FROM   v$logmnr_contents
where seg_name = 'LOG_MINER_TEST'
and username = 'USER_TEST'

Selectin çıktısı olarak sql_redo, sql_undo ve session_info kısımlarını ayrı olarak ekliyorum ;

USERNAME
TIMESTAMP
SEG_NAME
TABLE_SPACE
SID
SERIAL#
OPERATION
USER_TEST
02.08.2011 17:59
LOG_MINER_TEST
128
49
DDL
USER_TEST
02.08.2011 18:00
LOG_MINER_TEST
TEST_TBS
128
49
INSERT
Sql_redo;
insert into "USER_TEST"."LOG_MINER_TEST"("OWNER","TABLE_NAME","TABLESPACE_NAME","CLUSTER_NAME","IOT_NAME","STATUS","PCT_FREE","PCT_USED","INI_TRANS","MAX_TRANS","INITIAL_EXTENT","NEXT_EXTENT",
"MIN_EXTENTS","MAX_EXTENTS","PCT_INCREASE","FREELISTS","FREELIST_GROUPS","LOGGING","BACKED_UP","NUM_ROWS","BLOCKS","EMPTY_BLOCKS","AVG_SPACE","CHAIN_CNT","AVG_ROW_LEN",
"AVG_SPACE_FREELIST_BLOCKS","NUM_FREELIST_BLOCKS","DEGREE","INSTANCES","CACHE","TABLE_LOCK","SAMPLE_SIZE","LAST_ANALYZED","PARTITIONED","IOT_TYPE","TEMPORARY",
"SECONDARY","NESTED","BUFFER_POOL","ROW_MOVEMENT",
"GLOBAL_STATS","USER_STATS","DURATION","SKIP_CORRUPT","MONITORING","CLUSTER_OWNER",
"DEPENDENCIES","COMPRESSION","DROPPED") values ('SYS','CON$','SYSTEM',NULL,NULL,'VALID','10','40','1','255','65536',NULL,'1','2147483645',NULL,'1','1',
'YES','N','2786','12','0','0','0','20','0','0','         1','         1','    N','ENABLED','2786',TO_DATE('30/08/2005', 'DD/MM/RRRR'),'NO',NULL,'N','N','NO','DEFAULT','DISABLED','YES','NO',NULL,'DISABLED','YES',NULL,
'DISABLED','DISABLED','NO');
sql_undo;
delete from "USER_TEST"."LOG_MINER_TEST" where "OWNER" = 'SYS' and "TABLE_NAME" = 'CON$' and "TABLESPACE_NAME" = 'SYSTEM' and "CLUSTER_NAME" IS NULL and "IOT_NAME" IS NULL and "STATUS" = 'VALID' and "PCT_FREE" = '10' and "PCT_USED" = '40' and "INI_TRANS" = '1' and "MAX_TRANS" = '255' and "INITIAL_EXTENT" = '65536' and "NEXT_EXTENT" IS NULL and "MIN_EXTENTS" = '1' and "MAX_EXTENTS" = '2147483645' and "PCT_INCREASE" IS NULL and "FREELISTS" = '1' and "FREELIST_GROUPS" = '1' and "LOGGING" = 'YES' and "BACKED_UP" = 'N' and "NUM_ROWS" = '2786' and "BLOCKS" = '12' and "EMPTY_BLOCKS" = '0' and "AVG_SPACE" = '0' and "CHAIN_CNT" = '0' and "AVG_ROW_LEN" = '20' and "AVG_SPACE_FREELIST_BLOCKS" = '0' and "NUM_FREELIST_BLOCKS" = '0' and "DEGREE" = '         1' and "INSTANCES" = '         1' and "CACHE" = '    N' and "TABLE_LOCK" = 'ENABLED' and "SAMPLE_SIZE" = '2786' and "LAST_ANALYZED" = TO_DATE('30/08/2005', 'DD/MM/RRRR') and "PARTITIONED" = 'NO' and "IOT_TYPE" IS NULL and "TEMPORARY" = 'N' and "SECONDARY" = 'N' and "NESTED" = 'NO' and "BUFFER_POOL" = 'DEFAULT' and "ROW_MOVEMENT" = 'DISABLED' and "GLOBAL_STATS" = 'YES' and "USER_STATS" = 'NO' and "DURATION" IS NULL and "SKIP_CORRUPT" = 'DISABLED' and "MONITORING" = 'YES' and "CLUSTER_OWNER" IS NULL and "DEPENDENCIES" = 'DISABLED' and "COMPRESSION" = 'DISABLED' and "DROPPED" = 'NO' and ROWID = 'AAAMmXAAHAAAAKNAAA';
session_info;
login_username=USER_TEST client_info= OS_username=WINDB\Administrator Machine_name=CB\WINDB OS_terminal=WINDB OS_process_id=4720:488 OS_program_name=toad.exe
görüldüğü üzere yapmış olduğumuz insert işlemine karşılık sorunu düzeltmek adına delete scriptini verdi, delete işlemi yapmış olsaydık insert scriptini verecekti.
Son olarak log miner’ ın çalışma şeklinden biraz bahsetmek gerekirse, ana mantığı redologları okumaktan geçiyor sonrasında ise çıkan archive’ lar üzerinden okumaya devam ediyor. Dolayısıyla geçmişe dönük ne kadar archive’ ınız var ise o kadar geriye gidebilirsiniz demektir.

LOGMINER


 Oracle’da veri kurtarmak için kullanılabilecek ,kullanımı oldukça kolay olan ve hızlı bir şekilde sonuç alabileceğiniz bir yöntem; LOGMINER.
Kullanımı bu kadar basit olmasına  rağmen çok fazla bilinmediğini ve kullanılmadığını düşünüyorum.
Aslında bu yazıyı yaklaşık bir ay önce yazmaya karar vermiştim. Çünkü iki gün üst üste iki farklı canlı veritabanında kullanmak zorunda kaldım. Her iki durum da, müşteri uygulamalarından yanlışlıkla kayıt sildiklerini ve silinen bu kayıtları kurtarmak için farklı bir  ortama veritabanını Point In Time (PIT) recovery yapmak için benden destek istemeleri ile başladı.
         Olayı inceledikten sonra kayıtları silen personeli dinledikten sonra buna gerek olmadığını çok uzun sürecek Point In Time recovery yerine logminer kullanacağımı ve kısa sürede silinen kayıtları kurtarabileceğimizi anlattım.
         Bu yöntemi kullanabilmek için öncelikle bir takım ön koşullar var .
Bunlar;
1-işlemin hangi tablodan yapıldığı bilmek;
Bu olmazsa olmaz değil fakat işimizi hızlandıracaktır. Sorgulama yaparken seg_name ‘e göre arama yapabiliriz.
2-ilgili tablonun logging mode’unun enabled olması.
Tablo’nun logging modu’ enabled değilse o tablo üzerinde yapılacak delete , insert ve update işlemleri redo.log lara  yazılmayacağı için logminer kullanamayız.
3-işlemin yaklaşık olarak ne zaman yapıldığının bilinmesi,
Bize  hangi redo.log veya arşiv logları kullanacağımız hakkında fikir verecektir ve arama alanımızı kısıtlayacağı için daha hızlı sonuç alabiliriz.
LOGMINER ile kurtarma:
Veritabanına yapılan tüm değişiklik işlemleri redolog.lara oradan da arşiv.loglara aktarılmaktadır. Logminer ile de bu loglardaki yapılan işlemlere bakarak işlemleri geri alabiliriz.
İşlemin hangi saat aralığında yapıldığını tespit ettikten sonra alert.loga bakarak o saatler arasında işlemlerin hangi arşiv.loglarda veya redo.log da olduğu bulup bir kenara not ediyoruz.
Veritabanında hangi schema ait işlem yapıldığını ve tablo adını da aldıktan sonra işleme başlayabiliriz. İşlemlerimiz elbette yetkili bir kullanıcı ile yapıyoruz. Ben sys kullanıcısını kullandım.
Log dosyalarının logminer’a tanıtılması;
Bu kısımda  aradığımız işlemi barındırdığını düşündüğümüz redo.log ve arşiv.log dosyaları logminer’a tanıtılır.
BEGIN
  dbms_logmnr.add_logfile(‘/oracle/oradata/TEST/redo03.log’);
END;
/
Benim örneğimde kayıtların silinmesi redo03.log dosyasında olduğu düşünülerek sadece bu eklenmiştir.
Lomgminer işlemi başlatılır.
EXEC dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog);
Aradığımız kayıtların bulunması;
Tanıtmış olduğumuz redo03.log dan sorgulama yapılır. Burada benim kullandığım yöntem sorgulama yaparken bulunan kayıtların , tekrar sorgulama için bir tabloya yazdırılmasıdır.
Create table verikurtar as SELECT * FROM v$logmnr_contents  WHERE seg_owner=’SCHEMA_USER’ AND seg_name=’TABLO_ADI’   and operation =’DELETE’ ;
Buarada asıl amaç v$logmnr_contents in sorgulanmasıdır.
seg_owner=’SCHEMA_USER’      , tablonun sahibi olan kullanıcı
seg_name=’TABLO_ADI’            , kaydın silindiği tablo adı
operation =’DELETE’ ;                , aradığımız işlem
sorgulama işlemi tamamlandıktan sonra
SQL_REDO  kolonunda yapılan delete işlemi bulunur.
SQL_UNDO  kolonunda ise yapılan delete işlemini geri almak için kullanacağımız INSERT işlemi bulunur.
Sql_redo kolonundaki kayıtlar incelenerek yanlışlıkla silinen kayıtlar bulunur, bu Kayıların sql_undo sütünündaki insert cümleleri alınarak veritabanına uygulanır ve silinen kayıtlarınızı kurtarırız.
Logminer işlemi sonlandırılır.
exec dbms_logmnr.end_logmnr;  
Komutu çalıştırılarak işlemimiz sonlanmış olur.
Anlattığım örnekten de anlaşılacağı gibi , logminer yöntemi kullanılabiliyorsa Point In Time recovery kullanarak verilerimizi kurtarmak için harcayacağımız zaman ile kıyaslanamayacak  kısa ve kolay bir yöntemdir.
Caner BAŞTÜRK

26 Ocak 2011 Çarşamba

Oracle Alert ve Trace Dosyaları

ALERT VE TRACE DOSYALARI

Veritabani açilip kapatilirken veya bu asamanin adimlarinda herhangi bir hata durumunda olusan hatanin bilgileri alertSID.log dosyasina yazilir. Bu dosyada veritabani ile ilgili bütün bilgiler vardir. Dosyanin default yeri :

$ORACLE_HOME/rdbms/log

Lokasyonu BACKGROUND_DUMP_DEST parametresi ile belirlenebilir.

BACKGROUND TRACE

Background prosesler yürütülürken olusan hatalar sonucunda olusan dosyalardir. Lokasyonu BACKGROUND_DUMP_DEST parametresi ile belirlenir ve dosyanin formati SID_ProcessName_PID.trc seklindedir. Örnek olarak : db01_lgwr_23845.trc

USER TRACE

User prosessler üzerinde meydana gelen hatalar sonucunda olusan dosyalardir. Bu dosyalarin lokasyonu USER_DUMP_DEST parametresi ile belirlenir ve formati da SID_ora_PID.trc seklindedir. Örnek olarak : db01_ora_23845.trc bir user trace dosyasidir.

User Trace islemi yine bizde parametrelerce belirlenip yürütülebilen bir bilgidir.

Session bazli olarak,

SQL > ALTER SESSION SET SQL_TRACE = TRUE

Komutuyla,

Yada Paramatre file’indan

SQL_TRACE = TRUE yapilarak user trace enable edilebilir.

loglama bittikten sonra değeri FALSE yapmayı UNUTMAYIN!!!!


başka bir makale:

Veritabanı seviyesinde, yazılan kod ya da kod parçasında bir yavaşlık, performans düşüklüğü varsa bunun nedenini araştırmak gerekir.Bunu yapabilmenin en iyi yolu da “SQL Trace” almaktır.Peki nedir SQL Trace?

SQL Trace istenilen bir andan yine istenilen bir ana kadar olan zaman dilimi içersinde session ya da veritabanı seviyesinde gerçekleşen tüm olayların CPU da harcanan zaman, parse-execute-fetch aşamalarında gecen süre ve adet bilgileri , I/O miktarı gibi SQL in performansı ile direk alakalı bilgilerin okunabildiği ortamdır.TKPROF ta alınan bu SQL Trace’in okunabilirliğini arttırmaya yönelik Oracle ın bir ürünüdür.Öncelikle veritabanının trace dosyalarını nereye attığını tespit etmek gerekir.

select value from v$parameter where name = ‘user_dump_dest’

ile dosyaların atıldıgı dizin bilgisini alabiliriz.

NOT : ”USER_DUMP_DEST” bir init.ora parametresidir.SESSION bazında değil ama SYSTEM seviyesinde aşağıdaki komutla değiştirilebilir :
alter system set user_dump_dest=”d:sqltrace”;

SQL Trace dosyaları session bazlıdır, “kullanıcı(user)” bazlı değildir.Aşağıdaki script ile veritabanında bulunan kullanıcılara ait trace dosyaları bulunabilir :

select b.username, c.value || ‘\’ || lower(d.value) || ‘_ora_’ ||
to_char(a.spid, ‘fm00000′) || ‘.trc’ “TRACE_FILE”,
a.pid PID, b.serial# session_number
from v$process a, v$session b, v$parameter c, v$parameter d
where a.addr = b.paddr
and c.name = ‘user_dump_dest’
and d.name = ‘db_name’
and b.username is not null;

Burada dikkat edilmesi gerek bir başka nokta da oluşan trace dosyalarının isimlendirme yöntemidir.Örneğin yukardaki sorguda “_ora_” gibi bir formatlama yapıldı.9.x ve yukarısında bu şeklidedir.Aşağıda örnekler verilmiştir :

Version Isimlendirme şablonu Örnek

7.3.4 snnn_pid.trc s000_1234.trc
8.0.5 ora_pid_trc ora_1234.trc
8.1.7 ora_pid_instance.trc ora_1234_INSTNC1.trc
9.x-10g.x instance_ora_pid.trc INSTNC1_ora_1357.trc

Şimdi de SQL Trace ‘i “session” bazında alabilmek için yapılması gereken adımlara bakalım :

1) CPU da harcanan zaman, bekleme süreleri gibi bilgileri alabilmek için :alter session set timed_statistics = true;

2) SQL Trace i kullanabilmek için :
alter session set sql_trace = true;

NOT : Aynı işlem DBMS_SESSION.SET_SQL_TRACE(TRUE); ile de yapılabilir.

NOT : Bir DBA başka bir session içinde bu özelliği aktif edebilir.Bunun içinDBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid,serial#,sql_trace true/false);kullanılır.

Uygun ”sid” ve “serial#” degerleri ilgili kullanıcı için v$session tablosundan alınabilir.

3) Trace dosyasının boyutunu sınırsıza cekmek iyi olabilir :
alter session set max_dump_file_size =unlimited;

4) Her seviye de istatistik alabilmek için :
alter session set statistics_level = all ;

5) Oluşacak dosyanın adına okunabilirlik amacıyla eklenti yapmak için :
alter session set tracefile_identifier = ‘user_sql_trace’;

Örneğin normalde “xe_ora_3584.trc” adında olşacak olan dosya “xe_ora_3584_user_sql_trace.trc” adı ile oluşacaktır.

6) “wait events” bilgilerinin trace dosyasına yazıldıgından emin olmak için :alter session set events ‘10046 TRACE NAME CONTEXT FOREVER, LEVEL 8′;

7) Trace alacağımız kod çalıştırılır.(SQL , PL/SQL …) 8) Istediğimiz kod çalıştıktan sonra trace almayı durdurmak için :
alter session set sql_trace = false;NOT : işlem DBMS_SESSION.SET_SQL_TRACE(FALSE); ile de yapılabilir.

alter session set events ‘10046 TRACE NAME CONTEXT OFF’;

NOT: Yeterli miktar veri toplandığından emin olunduğunda trace özelliği kapatılmalıdır.Yoksa dosya şişer, diskte yer problemleri başlayabilir.Bu işlemler sonucunda “USER_DUMP_DEST” dizini altında “xxxuser_sql_trace.trc” adlı dosya oluşur.Ancak bu dosya okunabilirlik anlamında sıkıntı olan bir dosya.

Okunabilirliği arttırmak amacıyla Oracle “TKPROF” eklentisi yapmıştır.İşletim sisteminde “command prompt“ ta örneğin aşağıdaki gibi (Windows ta):tkprof ..\UDUMP\xe_ora_3060_user_sql_trace .trc D:\ sql_trace.txt explain=test/test sys=yes waits= yesşeklinde olabilir.

“UDUMP\xe_ora_3060_user_sql_trace .trc” - - > oluşan trace dosyası
“D:\ sql_trace.txt” - - > oluşacak yeni dosya adı
“explain=test/test sys=yes waits= yes” - - > TKPROF parametreleriPek çok TKPROF parametresi ve kullanımı var.Ihtiyaca göre set edilebilir.
Detay bilgiyi aşağıdaki linkten bulabilirsiniz :
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htmOluşan

trace dosyası örneğin aşağıdaki gibi olacaktır :
…………………..
PARSING IN CURSOR #8 len=41 dep=0 uid=0 oct=3 lid=0 tim=19068624436 hv=253931300 ad=’1d337414′
select * from ttest where object_id = 123
END OF STMT
PARSE #8:c=0,e=47,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=19068624429
EXEC #8:c=0,e=79,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=19068682136
WAIT #8: nam=’SQL*Net message to client’ ela= 9 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068691291
FETCH #8:c=0,e=89,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=19068700670
WAIT #8: nam=’SQL*Net message from client’ ela= 269 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068710270
FETCH #8:c=0,e=57,p=0,cr=1,cu=0,mis=0,r=0,dep=0,og=1,tim=19068720765
WAIT #8: nam=’SQL*Net message to client’ ela= 10 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068759424
WAIT #8: nam=’SQL*Net message from client’ ela= 347 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068769859
*** SESSION ID:(25.70) 2007-01-22 15:39:16.740
STAT #8 id=1 cnt=1 pid=0 pos=1 obj=14673 op=’TABLE ACCESS BY INDEX ROWID TTEST (cr=4 pr=0 pw=0 time=127 us)’
STAT #8 id=2 cnt=1 pid=1 pos=1 obj=14674 op=’INDEX RANGE SCAN TTEST_ID_IDX (cr=3 pr=0 pw=0 time=92 us)’
WAIT #0: nam=’SQL*Net message to client’ ela= 7 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068811087
WAIT #0: nam=’SQL*Net message from client’ ela= 335 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068821991
=====================
PARSING IN CURSOR #1 len=45 dep=0 uid=0 oct=7 lid=0 tim=19068832275 hv=349105966 ad=’1d0ef7cc’
DELETE FROM PLAN_TABLE WHERE STATEMENT_ID=:1
END OF STMT
PARSE #1:c=0,e=53,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=19068832269
EXEC #1:c=0,e=181,p=0,cr=3,cu=0,mis=0,r=0,dep=0,og=1,tim=19068887749
WAIT #1: nam=’SQL*Net message to client’ ela= 8 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068898228
WAIT #1: nam=’SQL*Net message from client’ ela= 145 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=19068908629
STAT #1 id=1 cnt=0 pid=0 pos=1 obj=0 op=’DELETE PLAN_TABLE$ (cr=3 pr=0 pw=0 time=106 us)’
STAT #1 id=2 cnt=0 pid=1 pos=1 obj=8655 op=’TABLE ACCESS FULL PLAN_TABLE$ (cr=3 pr=0 pw=0 time=96 us)’
…………………..

TKPROF kullandıktan sonra olusan dosya içeriği ise aşağıdaki gibi olacaktır :
…………………..
EXPLAIN PLAN SET STATEMENT_ID=’PLUS4294967295′ FOR select * from ttest where
object_id = 123
call count cpu elapsed disk query current rows
——- —— ——– ———- ———- ———- ———- ———-
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.03 0.20 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
——- —— ——– ———- ———- ———- ———- ———-
total 4 0.03 0.20 0 0 0 0

Hakkı Oktay
http://hakkioktay.wordpress.com



24 Kasım 2010 Çarşamba

initialization parametre değiştirme

öncelikle şu anki durmunu görüntülemek için

sqlplus ile bağlanıp

show parameter parametre_adı;

sonra

alter system set parametre_adı=değeri scope=spfile;

shutdown

startup

bu kadar :)

4 Şubat 2010 Perşembe

Dblink oluşturma ve veri taşıma

öncelikle plsql yada toad editörü açıp dblink oluştur diyoruz.(plsql de yapılması tavsiye edilir)

sonra dblink oluşturduğunuz target database de tnsnames ora lara(rac olduğu için lar diyorum)

source db nin bilgilerini eklemeniz lazım.

ve dblink iniz hazır :)

şimdi kopyalama işlemi için aşağıdaki gibi bir sorgu yeterli


create table ABONE_ADRES as
select * from schema_name.abone_adres@dbl_hizir;

buradaki schema_name tablo hangi schema da ise o schemanın adı
db1_hizir ise dblinkinizin adı

13 Ocak 2010 Çarşamba

Enterprise manager agent reconfigure

1- agent ı durdur

$PROMPT> cd AGENT_HOME/bin
$PROMPT> ./emctl stop agent

örn durumlar:
emctl start agent
emctl stop agent
emctl status agent

2-Locate the emd.properties file in the Management Agent home directory:

AGENT_HOME/sysman/config/emd.properties

3-Use a text editor to open the file and locate the REPOSITORY_URL property.

4-Modify the value for the REPOSITORY_URL property so it references the new Management Service.

For example:

REPOSITORY_URL=http://mgmthost2.acme.com:4889/em/upload

5-Modify the value for the emdWalletSrcUrl and emdWalletDest properties so they reference the new Management Service and the new Oracle home path, respectively:

For example, if the new Management Service is on a host called mgmthost2.acme.com and the new Oracle home is /private/oracle/em10g, modify the properties as follows:

emdWalletSrcUrl=http://mgmthost2.acme.com:4889/em/wallets/emd
emdWalletDest=/private/oracle/em10g/sysman/config/server

6-Save your changes and close the emd.properties file.

7-Delete all the files in the following directories:

AGENT_HOME/sysman/emd/upload/
AGENT_HOME/sysman/emd/state/
Note:

You can use the emctl clearstate agent command to delete the files in the state directory.
8-Restart the Management Agent.

ekstra işlemler


Securing the Management Agent
To secure the Management Agent of the new Management Service, use the following command:

emctl secure agent