Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

LOGGING kelimesi tablo, index veya tablespace oluştururken kullandığımız anahtar kelimedir. Objeyi oluştururken LOGGING kullanırsak ilgili obje üzerindeki DML işlemleri redo log dosyasında loglanır. NOLOGGING kullanılırsa log üretimi bazı durumlarda yapılmaz. LOGGING/NOLOGGING üzerine forumlarda bir çok soru sorulmaktadır. Sorulardan bazıları şu şekilde: NOLOGGING avantajı nedir? Ne zaman NOLOGGING kullanmalıyız? Tablespace düzeyinde NOLOGGING kullanıldıysa, bu tablespace içindeki tablolarımız LOGGING olabilir mi?

Tablespace seviyesindeki LOGGING/NOLOGGING kelimesi sadece bu tablespace içinde oluşturulacak objelerin varsayılan LOGGING durumunu tablespace ‘den miras (inherit) alması içindir. Şimdi test yaparak tek tek inceleyelim.

Önce NOLOGGING kullanarak NOLOGGING_TS adında bir tablespace oluşturuyorum.

CREATE TABLESPACE NOLOGGING_TS DATAFILE

‘/data_TALIPDB/nologging_ts.dbf’ SIZE 1024M AUTOEXTEND OFF

NOLOGGING

ONLINE

PERMANENT

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

Şimdi oluşturduğumuz NOLOGGING_TS tablespace içinde aşağıdaki gibi bir tablo oluşturalım ve tablo scriptimizde LOGGING/NOLOGGING ifadesini kullanmayalım;

CREATE TABLE talip_deneme (

id NUMBER

)

TABLESPACE nologging_ts;

Aşağıdaki sorgu ile baktığımızda tablomuzun NOLOGGING (LOGGING=NO) olarak oluşturulduğunu görürüz.

SELECT table_name, logging

FROM dba_tables

WHERE tablespace_name = ‘NOLOGGING_TS’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

Şimdi de tablomuzu aşağıdaki gibi LOGGING ifadesini kullanarak, oluşturduğumuz NOLOGGING_TS tablespace içinde oluşturalım.

CREATE TABLE talip_deneme2 (

id NUMBER

)

TABLESPACE nologging_ts

LOGGING;

Yukarıdaki sorgu ile baktığımızda tablomuzun LOGGING (LOGGING=YES) olarak oluşturulduğunu görürüz.

SELECT tablespace_name, logging

FROM dba_tables

WHERE table_name = ‘TALIP_DENEME2’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

TALIP_DENEME2 YES

O halde tablespace seviyesinde LOGGING/NOLOGGING kelimesinin kullanılması, bu tablespace içinde oluşturulacak objelerin varsayılan loglama durumunu tablespace ‘den alması içindir.

NOLOGGING olarak oluşturulan bir tablo sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLE talip_deneme LOGGING;

ALTER TABLE talip_deneme2 NOLOGGING;

Bu durum tablespace içinde geçerlidir. NOLOGGING olarak oluşturulan bir tablespace sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLESPACE nologging_ts LOGGING;

Bu durumda tablespace içinde önceden oluşturulan NOLOGGING objeler, NOLOGGING olarak devam edecektir. Bu tablespace içinde yeni oluşturulacak objelerin varsayılan loglama durumu LOGGING olacaktır. Yazımın başında NOLOGGING kullanılırsa log üretim işlemi bazı durumlarda yapılmaz demiştim. NOLOGGING kullanılırsa bazı durumlarda log üretimi devam edebilir. Peki bu durumlar nelerdir?

Tablo Log Durumu Insert Modu Arşiv Modu Redo Log üretimi
LOGGING APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING APPEND ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND ARCHIVE LOG REDO Üretilir
LOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
NOLOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND NO ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND NO ARCHIVE LOG REDO Üretilir

SQL*Loader veri yükleme yöntemlerinden birisi olan “Direct Path Load” işlemleri NOLOGGING bir tabloda redo log üretmez. Veritabanında “force logging” yapılmışsa, yani loglamaya zorlanmışsa, her zaman (LOGGING veya NOLOGGING) redo log üretilir. Tablo LOGGING modunda olsa bile veritabanı arşiv modu NO ARCHIVE LOG ise, “Direct Path Load” işlemleri redo log üretmez. Veritabanı arşiv modu ARCHIVE LOG ise, tablomuz LOGGING modunda redo log üretir. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretir. Veritabanı arşiv modu ARCHIVE LOG olsa bile tablomuz NOLOGGING modunda redo log üretmez. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretmez.

“Direct Path Load” dediğimiz işlem, buffer cache ‘i geçerek direk disk ile işlem yapar.

Bir tabloyu NOLOGGING oluşturmak LOGGING olarak oluşturmaktan daha kısa sürer. Basit bir test yapalım. Önce “dba_tables” görüntüsünün (view) bir kopyasını oluşturmak isteyelim. Önce LOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> set timing on

SQL> create table talip_logging logging as select * from dba_tables;

Table created.

Elapsed: 00:00:01.20

Şimdi de NOLOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> create table talip_nologging nologging as select * from dba_tables;

Table created.

Elapsed: 00:00:00.60

Süreleri inceledğimizde NOLOGGING işlem daha kısa sürdüğünü görüyoruz.

NOLOGGING yapılacak objeler genelde verisi hiç değişmeyen, sabit objelerdir. Versi hiç değişmeyen parametrik tablolar, doldur/boşalt tablolar örnek olarak verilebilir. Bu tip objelerin mutlaka tam (full) yedeği alınmalıdır. Aksi takdirde kurtarma (recover) işlemini gerçekleştiremezsiniz. Son olarak aklınıza şöyle bir soru gelebilir. NOLOGGING olarak açılan bir tabloda bir kaydı yanlışlıkla silersek artık rollback yapamam gibi bir durum söz konusu değildir. Tablonuz NOLOGGING olsa bile, yanlışlık sildiğiniz bir kaydı rollback ile geri getirebilirsiniz. Çünkü bu işlem UNDO dediğimiz segmentlerle alakalıdır. LOGGING/NOLOGGING tamamen redo ile alakalı bir durumdur. Bu durum ile alakalı da bir örnek yapalım. Önce NOLOGGING bir tablo oluşturalım;

CREATE TABLE talip_deneme3 (

isim varchar2(10)

)

NOLOGGING;

Tablomuza bir kayıt girelim;

insert into talip_deneme3 values(‘talip’);

commit;

Kaydımızı silelim;

delete from talip_deneme3;

rollback;

select * from talip_deneme3;

rollback yaptığımızda tablomuz NOLOGGING olduğu halde verimizin geri geldiğini gördük. Demek ki rollback işlemi LOGGING/NOLOGGING ile alakalı değildir.

Talip Hakan Öztürk

Reklamlar

Bir Triggerı Disable Olarak Oluşturabilir miyiz?

Merhaba Arkadaşlar,

Geçen bir yazılımcı arkadaşımdan bana triggerlar hakkında bir soru geldi.

Soru şöyleydi: Trigger’ı disable olarak oluşturmak istiyorum bu mümkün mü?

11g öncesine kadar tüm triggerlar oluşturulur oluşturulmaz varsayılan olarak enable durumdadır. Yani direk devreye girerler. Bu durum canlı sistemlerde istenilmeyen sıkıntılara yol açabilmekteydi.  11g öncesinde oluşturulan trigger, “ALTER TRIGGER trigger_name DISABLE;” cümlesi ile disable edilebilmekteydi.  Ancak trigger ‘ın oluşturulması ve disable edilmesi arasındaki zaman diliminde trigger’ın çalışma ihtimali olabilmektedir.

11g ile birlikte bu sorunumuz aşağıdaki örnekte olduğu gibi DISABLED TRIGGER ile çözülmüştür. 11g ile Trigger oluşturulurken direk disable olarak oluşturulabilmektedir.

CREATE OR REPLACE TRIGGER TALIP_TEST_TRIG
BEFORE INSERT ON TALIP_TEST
FOR EACH ROW
DISABLED
BEGIN
:NEW.TARIH := SYSDATE;
END;

Talip Hakan Öztürk

ORA-06508 | ORA-04065 | ORA-04068 Hatalarını Nasıl Çözeriz?

Merhaba Arkadaşlar,

Bu yazımda, ORA-06508, ORA-04065, ORA-04068 hataları ile karşılaştığımızda ne yapmamız gerektiğini yazacağım. Bir paket veya prosedür içinden çağırılan bağımlı bir nesne, DDL cümlesi ile değiştirildiğinde, çağıran paket veya prosedür ORA-04068 hatası ile karşılaşır. Bunun sebebi paketler derlendiklerinde shared_pool alanındaki kopyaları invalid olarak işaretlenir. Bu esnada çağıran paket çağrılan paketin yeni bir kopyasının olduğunu anlar. Ve ORA-04068 hatası alınır. Çağıran paket veya procedure bu hatayı ilk çağırdığı esnada alır. İkinci kez çağırdığında işlem başarılı olarak gerçekleştirilir. Ama bazı durumlarda bu hatalardan kurtulmak için kodumuzda küçük bir değişiklik yapmamız gerekebilir.

Şimdi bu konu ile ilgili bir test yapalım. Aşağıdaki gibi talip_test adında bir paket oluşturuyorum. Paketin SPEC kısmında global bir değişken tanımlayalım.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

Şimdide bu paketi çağıracak olan bir procedure oluşturalım.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
END;
/

SQL*Plus üzerinde prosedürü çalıştırdığımızda başarılı çalıştığını görürüz.

SQL> set serveroutput on

SQL> begin outer_test_proc; end; /

Değişken =12

PL/SQL procedure successfully completed.

Şimdi talip_test paketinin SPEC kısmında biraz değişiklik yapalım. İkinci bir global değişken ekleyelim. Ve SPEC+BODY yeniden derleyelim.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;
global_var2 NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

outer_test_proc prosedürü invalid olacaktır. Prosedürümüzü aşağıdaki gibi derleyelim.

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

INVALID

SQL> alter procedure outer_test_proc compile ;

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

VALID

Bu durumda veritabanına bağlı olan oturumlar (session) prosedürü çağırdıklarında aşağıdaki gibi ORA-04068 hatası alırlar. Paketi çağıran oturum bu hatayı sadece bir kere alır.

SQL>begin outer_test_proc; end; /

begin outer_test_proc; end;

* ERROR at line 1: ORA-04068: existing state of packages has been discarded

ORA-04061: existing state of package body “TALIP.TALIP_TEST” has been invalidated

ORA-04065: not executed, altered or dropped package body “TALIP.TALIP_TEST”

ORA-06508: PL/SQL: could not find program unit being called: “TALIP.TALIP_TEST”

ORA-06512: at “TALIP.OUTER_TEST_PROC”, line 5 ORA-06512: at line 1

Aynı oturum ikinci kez çalıştırdığında paket başarılı çalıştırılır.

SQL> set serveroutput on

SQL> /

Değişken =12

PL/SQL procedure successfully completed.

Çağıran paket veya procedure de “when others then” ile exception handling yapılıyorsa, veritabanına bağlı oturumlar paketi her çağırdıklarında hata alırlar. Şimdi outer_test_proc prosedürümüzü aşağıdaki gibi değiştirelim.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
EXCEPTION
WHEN OTHERS
THEN
err := SUBSTR (SQLERRM, 0, 1000);
DBMS_OUTPUT.put_line (err);
ROLLBACK;
END;
/

Şimdi talip_test paketinin SPEC kısmında biraz değişiklik yapalım. Üçüncü bir global değişken ekleyelim. Ve SPEC+BODY yeniden derleyelim.

CREATE OR REPLACE PACKAGE talip_test
IS
global_var NUMBER := 10;
global_var2 NUMBER := 10;
global_var3 NUMBER := 10;

PROCEDURE inner_test_proc;
END;
/

CREATE OR REPLACE PACKAGE BODY talip_test
IS
PROCEDURE inner_test_proc
IS
BEGIN
global_var := global_var + 1;
DBMS_OUTPUT.put_line (‘Değişken =’ || global_var);
END;
END;
/

outer_test_proc prosedürü invalid olacaktır. Prosedürümüzü aşağıdaki gibi derleyelim.

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

INVALID

SQL> alter procedure outer_test_proc compile ;

SQL> select status from dba_objects where object_name=’OUTER_TEST_PROC’;

STATUS

——-

VALID

Bu durumda outer_test_proc prosedürü valid olmasına rağmen, veritabanına bağlı oturumlar outer_test_proc prosedürünü her çağırdıklarında ORA-06508 hatası alırlar.

SQL> begin outer_test_proc; end; /

ORA-06508: PL/SQL: could not find program unit being called

PL/SQL procedure successfully completed.

SQL> /

ORA-06508: PL/SQL: could not find program unit being called

PL/SQL procedure successfully completed.

“when others then” bloğu içerisinde exception tekrar aşağıdaki gibi raise edilirse, bağlı oturumlar prosedürü ilk çağırdıklarında hata alırlar ve ikinci kez çağırdıklarında işlem başarılı gerçekleşir.

CREATE OR REPLACE PROCEDURE outer_test_proc
AS
err VARCHAR2 (1024);
BEGIN
talip_test.inner_test_proc;
EXCEPTION
WHEN OTHERS
THEN
err := SUBSTR (SQLERRM, 0, 1000);
DBMS_OUTPUT.put_line (err);
ROLLBACK;
RAISE;
END;
/

Şimdi terkrar çalıştıralım. İlk çalıştırdığımızda hata alacağız. Tekrar çalıştırdığımızda işlem başarılı gerçekleşecektir.

SQL> begin outer_test_proc; end; /

begin outer_test_proc; end;

* ERROR at line 1: ORA-04068: existing state of packages has been discarded

ORA-04061: existing state of package “TALIP.TALIP_TEST” has been invalidated

ORA-04065: not executed, altered or dropped package “TALIP.TALIP_TEST”

ORA-06508: PL/SQL: could not find program unit being called: “TALIP.TALIP_TEST”

ORA-06512: at “TALIP.OUTER_TEST_PROC”, line 11 ORA-06512: at line 1

SQL> /

PL/SQL procedure successfully completed.

Faydalı olması dileğiyle…

Talip Hakan Öztürk

SQL Tuning Setin (STS) Veritabanları Arasında Taşınması

Veritabanımızda problemli SQL cümlelerimiz incelemek ve tune etmek için SQL Tuning Set oluşturabiliriz. Oluşturduğumuz STS ‘yi test veritabanımıza aktarmak için Oracle Enterprise Manager konsolunun kullanabileceğimiz gibi kendimiz de DBMS_SQLTUNE paketini kullanarak taşıma işlemini gerçekleştirebiliriz. Zaten OEM konsoluda arka planda DBMS_SQLTUNE paketini kullanarak taşıma işlemini gerçekleştirmektedir.

Taşıma işlem adımları aşağıdaki gibidir.

1- STS için bir ara tablo (staging table) oluşturulur

BEGIN

DBMS_SQLTUNE.create_stgtab_sqlset (table_name => ‘STG_TABLE’,

schema_name => ‘TALIP’,

tablespace_name => ‘TALIP_TS’

);

END;

/

2- STS pack edilerek bu ara tabloya aktarılır.

BEGIN

DBMS_SQLTUNE.pack_stgtab_sqlset (sqlset_name => ‘STS_TALIP’,

sqlset_owner => ‘TALIP’,

staging_table_name => ‘STG_TABLE’,

staging_schema_owner => ‘TALIP’

);

END;

/

3- Ara tablonun (staging table) exportu alınır ve alınan export STS ‘in taşınacağı sunucuya kopyalanır.

exp userid=talip@dbtalip file=stg_table.dmp log=stg_table.log tables=talip.stg_table compress=no recordlength=65535 direct=y feedback=1000000 CONSISTENT=N

3 tablonun exportu alınacaktır. Bu tablolar “STG_TABLE” , “STG_TABLE_CBINDS” ve “STG_TABLE_CPLANS” tablolarıdır. İlk tablo sql cümlelerimizi, ikinci tablo sql cümlelerimizde kullanılan bind değerleri (STS ilk alınırken bind seçilmemişse, bu tablo kayıt içermez) ve son tablo ise sql cümlelerimizin execution planlarını içermektedir.

4- Ara tablo (staging table) test veritabanımıza import edilir.

imp userid=talip@testdb file=stg_table.dmp log=stg_table_imp.log fromuser=talip touser=talip recordlength=65535 feedback=1000000

5- Ara tablodan STS unpack edilerek import işlemi gerçekleştirilir.

BEGIN

DBMS_SQLTUNE.unpack_stgtab_sqlset (sqlset_name => ‘STS_TALIP’,

sqlset_owner => ‘TALIP’,

replace => TRUE,

staging_table_name => ‘STG_TABLE’,

staging_schema_owner => ‘TALIP’

);

END;

/

STS, test veritabanımızda hazırdır. Artık SQL cümlelerimizi istediğimiz gibi inceleyebiliriz 🙂

Talip Hakan Öztürk

Oracle Veritabanı Deployment Analizi

ORACLE VERİTABANI DEPLOYMENT ANALİZİ

Bu makalemde oracle veritabanı obje (package, procedure, function, tablo, index) taşımalarında yapmamız gereken bağımlılık (dependency) analizinden bahsedeceğim.

Analiz edilmeden taşınan obje, veritabanında ciddi problemler oluşturabilmekte ve hatta servis kesintisi ile kurum vizyonuna zarar verebilmektedir. Veritabanına taşımayı düşündüğümüz objenin çok fazla bağımlılığı olabilir. Ve yaptığımız işleme görede bağımlı objeler invalid duruma düşebilmektedir. Invalid duruma düşen obje son kullanıcı tarafından kullanılmadan derlenirse herhangi bir problem oluşturmamaktadır. Eğer invalid duruma düşen obje son kullanıcı tarafından çok çağrılan (kullanılan) bir obje ise, bu durum objeyi derlememize engel olacağı gibi son kullanıcının hata almasınada sebep olacaktır.

Hizmet kalitesi olarak performans, bizim için en önemli unsurlardan biridir. Internet şubeden hesap hareketlerini inceleyen, havale, fatura ödemesi yapan müşterimiz, yapmış olduğu işlemi en kısa sürede problemsiz tamamlamak ister. Sürekli yavaşlıktan şikayetçi olan bir müşteri, üstüne iyilik birde yukarıda bahsettiğim gibi analizsiz taşımalar sonucu sürekli hata ile karşılaşırsa ilgili kurum ile çalışmaktan vazgeçecektir.

Peki obje taşımalarımızda nelere dikkat etmeliyiz? Bağımlıklıkları nasıl analiz etmeliyiz? Şimdi bu sorulara cevap arayalım. Obje taşımalarında hangi durumlara dikkat etmemiz gerektiğini başlıklar altında tek tek inceleyelim.

Obje bağımlılık (dependency) durumunu aşağıdaki sorgu ile kontrol edebiliriz. Aşağıdaki sorgu sonucunda en az 1 kayıt (objenin kendisi) gelmelidir. Bu durum objenin varlığını gösterir. Hiç kayıt gelmiyorsa veritabanında böyle bir obje yoktur. Eğer kayıt sayısı çok fazla ise bağımlılık fazla olduğundan dolayı dikkat edilmeli ve obje tipine göre aşağıdaki adımlar izlenmelidir.

SELECT name FROM dba_dependencies d  WHERE (d.referenced_name,d.referenced_type) in(
SELECT name,type FROM dba_dependencies d1 WHERE d1.referenced_name IN ('OBJECT_NAME')
)
UNION
SELECT name FROM dba_dependencies d2 WHERE d2.referenced_name IN ('OBJECT_NAME')
UNION
SELECT object_NAME FROM dba_objects WHERE object_NAME IN ('OBJECT_NAME')

1- SP TAŞIMALARI:
Package taşımalarında dikkat etmemiz gereken SPEC olup olmamasıdır. Eğer SPEC varsa bağımlı olan bütün objeleri düşürecektir. Bu durumda bu paketin kullanım yoğunluğuna bakılmalıdır. Kullanım yoğunluğu ve sıklığı çok fazla ise taşıma güniçi yapılmamalıdır. Aşağıdaki script ile kullanım yoğunluğunu tespit edebiliriz.

SELECT name, loads, executions, pins,c.*
FROM v$db_object_cache c
WHERE name in
(SELECT name FROM dba_dependencies d  WHERE (d.referenced_name,d.referenced_type) in(
SELECT name,type FROM dba_dependencies d1 WHERE d1.referenced_name IN ('OBJECT_NAME')
)
UNION
SELECT name FROM dba_dependencies d2 WHERE d2.referenced_name IN ('OBJECT_NAME')
UNION
SELECT object_NAME FROM dba_objects WHERE object_NAME IN ('OBJECT_NAME'))
AND pins >0;

2- ADD, DROP, MODIFY COLUMN Komutları:
Tabloya kolon ekleme, silme, değiştirme (ADD, DROP, MODIFY) ve Constraint modify işlemleri yapan scriptler tabloyu kullanan SP leri invalid duruma düşürecektir. İlgili tablo için bağımlılık analizi yapılmalıdır. Analiz sonucuna göre deployment planlanmalıdır.

3- ADD, DROP CONSTRAINT Komutları:
Tabloya constraint ekleme/kaldırma (ADD, DROP CONSTRAINT) işlemlerinde PK/FK constraint tipinde ve bütün tipler için VALIDATE modunda tabloya kilit atıldığı için gün içinde yapılmamalıdır.

Diğer constraint tiplerinde mutlaka NOVALIDATE parametresi ile komut çalıştırılmalıdır.

4- CREATE INDEX komutu:
CREATE INDEX komutu ile index açılırken ilgili tabloya kilit atıldığı için bu tablonun çok kullanılan bir tablo olmadığından emin olunmalıdır.

5- CREATE TRIGGER komutu:
Create trigger komutu ile trigger oluşturma işlemi tablo üzerinde kilit oluşturmaz. Gün içerisinde çok fazla insert görmeyen bir taloya insert trigger i gün içerisinde yapılabilir. Ancak çok sık insert gören tablolara, insert işlemiyle tetiklenen trigger eklenmesi durumunda kısa süreli pinleyememe sorununa yol açmaktadır.

6- CREATE TABLE komutu:
Tablo create scriptinin içindeki constraintler incelenmelidir. Sade bir tablo create scripti sorun çıkarmayacaktır. Ama içerisinde PK/FK constraint var ise dikkatli olunmalıdır. Çünkü bu durum 3. Maddede belirttiğim gibi ilişkili tabloya kilit atacaktır.

Sağlıklı çalışan, problemsiz deploymentların olduğu mutlu veritabanlarımız olması dileğiyle. Sağlıcakla kalın… 🙂 🙂

Talip Hakan ÖZTÜRK