Talend Interview Questions and Answers | Talend Online Training | Talend Tuto...Edureka!
( Talend Training: https://www.edureka.co/talend-for-big-data)
This Edureka tutorial on Talend Interview Questions will help you to learn about the most frequently asked Talend questions and their answers which will set you apart in the interview process. This video helps you to learn the following topics:
1. Talend MCQ
2. General Talend Questions
3. Talend for Data Integration Questions
4. Talend for Big Data Questions
***** Talend Training: https://www.edureka.co/talend-for-big-data *****
This Edureka tutorial on Talend Components will demonstrate the usage of few of the majorly used components in Talend like tMap, tJoin, tFileInputDelimited, tMysqlRow etc.This video helps you to learn the following topics:
1. What is Talend?
2. Talend Component Families
3. Talend File Components
4. Talend Processing Components
5. Talend Database Components
Instantly convert Teradata ETL and EDW to Spark- Impetus webinarImpetus Technologies
Teradata has been a popular choice for analytical data processing. As data complexity increases, more and more enterprises need the flexibility and scalability advantages of ‘modern data architecture’ technologies. The sophisticated algorithmic and statistical analytics, and interoperability, would also enable businesses to handle vast and complex data at high speeds.
But the challenges and risks involved in an enterprise data warehouse transformation are well known. Impetus Workload Transformation solution is the only 100% cloud ready solution to assess, migrate, and validate your complex data transformation and analytical workloads from Teradata to modern open systems such as Spark, Hive or Scala. Find out how your enterprise can ensure a swift move to big data / cloud using an automation based EDW transformation solution.
Join our upcoming webinar where our modern data architecture experts will talk about:
Using automation to identify the candidate workloads to migrate
Building a prioritized EDW conversion roadmap based on cost, performance, and business objectives
Devising an effective offload strategy to a scalable data architecture
Rapidly transforming complex business logic and code (with UDFs) using automation.
To view the webinar, visit - https://bit.ly/347S19N
Design and develop with performance in mind
Establish a tuning environment
Index wisely
Reduce parsing
Take advantage of Cost Based Optimizer
Avoid accidental table scans
Optimize necessary table scans
Optimize joins
Use array processing
Consider PL/SQL for “tricky” SQL
Talend Interview Questions and Answers | Talend Online Training | Talend Tuto...Edureka!
( Talend Training: https://www.edureka.co/talend-for-big-data)
This Edureka tutorial on Talend Interview Questions will help you to learn about the most frequently asked Talend questions and their answers which will set you apart in the interview process. This video helps you to learn the following topics:
1. Talend MCQ
2. General Talend Questions
3. Talend for Data Integration Questions
4. Talend for Big Data Questions
***** Talend Training: https://www.edureka.co/talend-for-big-data *****
This Edureka tutorial on Talend Components will demonstrate the usage of few of the majorly used components in Talend like tMap, tJoin, tFileInputDelimited, tMysqlRow etc.This video helps you to learn the following topics:
1. What is Talend?
2. Talend Component Families
3. Talend File Components
4. Talend Processing Components
5. Talend Database Components
Instantly convert Teradata ETL and EDW to Spark- Impetus webinarImpetus Technologies
Teradata has been a popular choice for analytical data processing. As data complexity increases, more and more enterprises need the flexibility and scalability advantages of ‘modern data architecture’ technologies. The sophisticated algorithmic and statistical analytics, and interoperability, would also enable businesses to handle vast and complex data at high speeds.
But the challenges and risks involved in an enterprise data warehouse transformation are well known. Impetus Workload Transformation solution is the only 100% cloud ready solution to assess, migrate, and validate your complex data transformation and analytical workloads from Teradata to modern open systems such as Spark, Hive or Scala. Find out how your enterprise can ensure a swift move to big data / cloud using an automation based EDW transformation solution.
Join our upcoming webinar where our modern data architecture experts will talk about:
Using automation to identify the candidate workloads to migrate
Building a prioritized EDW conversion roadmap based on cost, performance, and business objectives
Devising an effective offload strategy to a scalable data architecture
Rapidly transforming complex business logic and code (with UDFs) using automation.
To view the webinar, visit - https://bit.ly/347S19N
Design and develop with performance in mind
Establish a tuning environment
Index wisely
Reduce parsing
Take advantage of Cost Based Optimizer
Avoid accidental table scans
Optimize necessary table scans
Optimize joins
Use array processing
Consider PL/SQL for “tricky” SQL
MSSQL SERVER 2008 REPLICATION (PEER TO PEER)Minh Tri Lam
MSSQL SERVER 2008 REPLICATION
PEER TO PEER REPLICATION
DATABASE REPLICATION
cloud computing, database, dong bo du lieu, mssql server replication, peer to peer replication, sync database, synchronize,sync db
Talend ETL Tutorial | Talend Tutorial For Beginners | Talend Online Training ...Edureka!
( Talend Training: https://www.edureka.co/talend-for-big... ) This Edureka PPT on Talend ETL Tutorial [Talend ETL Tutorial Blog: https://goo.gl/myMwuQ] will help you in understanding the basic concepts of ETL (Extract, Transform & Load) process and how Talend helps in simplifying the entire ETL process by integrating them into a single Job. This video helps you to learn following topics: Why ETL? What Is ETL? ETL Tools Talend As An ETL Tool Demo
Talend Open Studio Introduction - OSSCamp 2014OSSCube
Talend Open Studio is the most open, innovative and
powerful data integration solution on the market today. Talend Open Studio for Data Integration allows you to
create ETL (extract, transform, load) jobs.
MSSQL SERVER 2008 REPLICATION (PEER TO PEER)Minh Tri Lam
MSSQL SERVER 2008 REPLICATION
PEER TO PEER REPLICATION
DATABASE REPLICATION
cloud computing, database, dong bo du lieu, mssql server replication, peer to peer replication, sync database, synchronize,sync db
Talend ETL Tutorial | Talend Tutorial For Beginners | Talend Online Training ...Edureka!
( Talend Training: https://www.edureka.co/talend-for-big... ) This Edureka PPT on Talend ETL Tutorial [Talend ETL Tutorial Blog: https://goo.gl/myMwuQ] will help you in understanding the basic concepts of ETL (Extract, Transform & Load) process and how Talend helps in simplifying the entire ETL process by integrating them into a single Job. This video helps you to learn following topics: Why ETL? What Is ETL? ETL Tools Talend As An ETL Tool Demo
Talend Open Studio Introduction - OSSCamp 2014OSSCube
Talend Open Studio is the most open, innovative and
powerful data integration solution on the market today. Talend Open Studio for Data Integration allows you to
create ETL (extract, transform, load) jobs.
1. TABLESPACE VE DATAFILE YÖNETİMİ
Oracle Veritabanı üzerinde dataların yani verilerin saklandığı yer fiziksel olarak DataFile mantıksal olarak
ise TableSpace olarak ifade edilmektedir.
Bir Database’in veri saklanmasının hiyerarşik olarak saklanması ise aşağıdaki şekilde görüldüğü gibidir.
2. Tablespace
Bir tablespace bir beya birden fazla datafile içerebilmektedir,
Tablespace ler üzerinde ki işlemler Tablespace online iken yapılmaktadır.
System Table space kesinlikle undo yada temp tablespace olarak kullanılmamalıdır,
Tablespaceler read only yada normal mod arasında çevrim yapılabilirler.
DataFile
Bir DataFile yalnızca bir tablespace e verilebilir.
Büyüklüğü ve optimizasyonu değiştirilebilir
Segment
Bir Datafile bir yada birden fazla segment içerebilir,
Bir segment birden fazla Tablespace e dağılabilir
Extends
Bir Segment bir veya daha fazla extend ten oluşur,
Bir segment yaratıldığında tek extend vardır ama daha sonra arttırılabilir,
DataBlocks
Extandler içinde bulunan en küçük birimdir,
Boyutu DB_BLOCK_SIZE ile Database yaratılırken belirlenir ve daha sonra değiştirilemez.
Database bloklarının büyüklüğü işletim sistemi ile doğru orantılıdır,
3. Standart blok uzunluğu başlangıç parametresi DB_BLOCK_SIZE tarafından belirlenir. Ayrıca, standart
olmayan beş blok büyüklüğüne kadar belirleyebilirsiniz. Gereksiz giriş/çıkıştan kaçınmak için, veri blok
uzunluğu, maksimum sınırlar içinde işletim sisteminin blok uzunluğunun bir kaç katı olmalıdır. Oracle’ın
kullandığı veya ayırdığı en küçük depo birimi Oracle veri bloğudur
Tablesapce ler mantık olarak ikiye ayrılır,
System Tablespace
Database Yaratılırken oluşmuşlar,
İçerisinde Datadictionary bilgisi bulundururlar,
System Undosegmentinde bilgi barındırırlar
Non System TableSpace
Kullanıcı tarafından oluşturlmuşlardır,
Kullanıcı datasını tutarlar,
İndex Segment,Data Segment,Temp Segment buna örnektir
4. Bir tablespace şu şekilde oluşturulmaktadır,
Database açıkken yapılır.
SQL> CREATE TABLESPACE emo_deneme
DATAFILE 'D:oracleoradatanewdbdeneme01.dbf' SIZE 100M
AUTOEXTEND ON NEXT 5M MAXSIZE 200M;
SQL> CREATE TABLESPACE tablespace
[DATAFILE clause]
[MINIMUM EXTENT integer[K|M]]
[BLOCKSIZE integer [K]]
[LOGGING|NOLOGGING]
[DEFAULT storage_clause ]
[ONLINE|OFFLINE]
[PERMANENT|TEMPORARY]
MINIMUM EXTENT
TableSpace in alacağı minimum büyülüğktür,Kilobyte yada MegaByte olarak verilebilir
LOGGING
Yapılacak her değişikilkiğin redolara yansıyıp yansımayacağı belirlenir.Bu değer verilmişse
yansıyacaktır.Logging defaulttur.
NOLOGGING
Yapılacak her değişikilkiğin redolara yansıyıp yansımayacağı belirlenir.Bu değer verilmişse
yansımayacaktır.Logging defaulttur.
INITIAL
Tablesapce ilk oluştuğunda alacağı genişleme büyüklüğü(ilk extendin boyutu)
5. NEXT
pctincrease paametresi ile birlikte sonraki extendlerin boyutunu belirler
PCTINCREASE
Sonraki Extendlerin % kaç artacağını belirtir.
MINEXTENTS
Tablespace ilk oluştuğunda atanacak en az extend sayısı
MAXEXTENTS
Tablespace ilk oluştuğunda ve daha sonrası için atanacak en fazla extend sayısı
Alan Yönetimi bakımından ise tablespace ler yine ikiye ayrılmaktadır.
Localy Management ve Dictionary Management olarak.
Localy Management TableSpaces
Bu Yöntemde yerel olarak yönetilceği belirtilen tablo aralıklarına ait veri dosyasında bir BİTMAP
bulunur.Bu BİTMAP ilgili veri dosyasındaki veri bloklarının kullanını kaydeder.İlgili tablo aralığındaki ilgili
bir nesneye extend atanması veya geri alınması durumunda Oracle veri sözlüğüne herhangi bir yazma
yapmadan ilgili veri dosyasındaki BİTMAP’i günceller.
Yerel olarak yönetilecek bir tabloaralığı yönetmek için exent management local ifadesi
kullanılmalıdır.next,pctincrease,minextends,maxextends ifadeleri kullanılmaz.Bu tür tablo aralıklarında tüm
extendler aynı boyda olur yada sadece ilk extend boyutu belirtilir ve oracle diğer extend boyutlarını
otomatik olarak ayarlar.Aynı boyda extendletanması için UNİFORM,oracle’ın extend boyutunu otomatik
belirlemesi isteniyorsa de AUTOALLOCATE kullanılır.
SQL > CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/userdata01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;
SQL > CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/userdata01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
6. Yerel yönetilen tablespaceler extend atama ve geri alma yükünü azltmaktadır,çünkü bu bilgiler hem veri
sözlüklerine hemde rollback segmentlere yazılmaktadır,Veri sözlüğüne yazma ve boş alan
birleştirme(Coalesce) işlemi ortdan kalkmaktadır.
Dictionary Managemnt TableSpaces
Bu Yöntemde extendler dictionary viewlar ile yönetilir.Boş alan birleştime(Coalsece) işlemi kesinlikle
gereklidir.
SQL >CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/userdata01.dbf' SIZE 500M
EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE ( initial 1M NEXT 1M );
SQL > ALTER TABLESPACE userdata
MINIMUM EXTENT 2M;
SQL > ALTER TABLESPACE userdata
DEFAULT STORAGE (
INITIAL 2M
NEXT 2M
MAXEXTENTS 999 );
7. UNDO TABLESPACES
Undosegmentleri depolamak için kullanılırlar,Başka herhangi bir obje içermezler,Extend yönetimi localy
managed şeklindedir.
SQL > CREATE UNDO TABLESPACE undo1
DATAFILE '/u01/oradata/undo101.dbf' SIZE 40M;
TEMPORARY TABLESPACES
Sıralama işlemleri için kullanılırlar,Başka herhangi bir obje içermezler,Extend yönetimi localy
managementtır.
SQL > CREATE TEMPORARY TABLESPACE temp
TEMPFILE '/u01/oradata/temp01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;
•
TempFile’lar her zaman NOLOGGING modadır,
•
Bir Tempfile Read only yapılamaz,
•
Bir temp file’ın ismi değiştirilemez,
•
Tempfile lar read only db ler için gereklidir,
•
Media recovery ile temp file lar onarılmaz,
•
Backup Control file komutu temp file bilgisi içermez,
•
Create Control file cümlesi de temp file bilgisi içermez
DEFAULT TEMPORARY TABLESPACES
Default Temp Tablespace vererek System tablespace’nin kullanılması engellenir.Daha sonrası için alter
edilerek değiştirilebilir.Create database ile create edilen temp tablespace localy managed dir.Yenisi
yazılana kadar eskisi asla drop edilemez.Offline moda alınamaz,default tablespcae normal tablespace e
çevrilemez.
SQL > ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
Tablespace’lerin içeriği ve şekli gibi bilgileri değişirmekte mümkündür.Yani bir tablespace in boyutu
arttıralbilir,yeni bir data file eklenebilir,Online yada offline yapılabilir.
8. Offline yapılan bir tablespace e veri erişimi yapılamaz.
Ama şuna dikkat edilmelidir.Bazı tablespace’ler kesinlikle Online olmalıdır.Örneğin aktif olan undo
segment,System tablespace’i ve defaul temp tablespace,
SQL > ALTER TABLESPACE userdata OFFLINE;
SQL > ALTER TABLESPACE userdata ONLINE;
Backup alınırken bir tablespace açıkken backup’ı alınmamalıdır,ya offline yada backup modunda
alınmalıdır.
Tablespace’leri Read Only moda getimekte mümkündür,
Bu durumlarda yalnızca okuma yapılabilir,Tablespace ten bir obje drop edilebilir
ALTER TABLESPACE tablespace READ [ONLY | WRITE]
SQL > ALTER TABLESPACE userdata READ ONLY;
DROP TABLESPACES
İlgili tablespace datadictionary den silinir,sonuna and datafiles ifadesi konulursa ilgli distende silinir.
SQL > DROP TABLESPACE userdata
INCLUDING CONTENTS AND DATAFILES;
RESIZING TABLESPACES
Tablespace lerin boyutlarını otomatik olarak değiştirebileceğimiz gibi ellede yapabilmek mümkündür,
9. Eğer tablespace için autextend koyarsak büyümesi verdiğimiz oranda otomatik olarak olacaktır.
SQL > ALTER DATABASE DATAFILE
'/u01/oradata/userdata02.dbf' SIZE 200M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M;
SQL > ALTER DATABASE
DATAFILE '/u03/oradata/userdata02.dbf'
RESIZE 200M;
10. SQL > ALTER TABLESPACE app_data
ADD DATAFILE '/u01/oradata/userdata03.dbf'
SIZE 200M;
MOVİNG TABLESPACES
İlgili tablespace’in yeri değiştirilmek isteniyorsa ilk önce tablespace offline moda alınır.Daha sonra işletim
sisteminden yeri değiştirilir.Daha sonra rename komutu ile ilgili yere işlenmesi sağlanır.Daha sonra online
moda alınır.
SQL > ALTER TABLESPACE userdata OFFLINE;
CMD > mv '/u01/oradata/userdata01.dbf' '/u01/oradata/userdata03.dbf'
SQL > ALTER TABLESPACE userdata
RENAME
DATAFILE '/u01/oradata/userdata01.dbf'
11. TO '/u01/oradata/userdata03.dbf';
SQL > ALTER TABLESPACE userdata ONLINE;
DEFAULT PATH FOR TABLESPACES
Yaratılacak datafilelar için otomatik olarak bir destionation path verilmesi sağlanır.
SQL > ALTER SYSTEM SET
db_create_file_dest = '/u01/oradata/db01';
Tablespace ve data fillar ile ilgili detaylı bilgileri yine dictionary file lardan bulabiliriz.
Tablespace information:
– DBA_TABLESPACES
– V$TABLESPACE
Data file information:
– DBA_DATA_FILES
– V$DATAFILE
Temp file information:
– DBA_TEMP_FILES
– V$TEMPFILE
12. DEPOLAMA YAPILARI VE İLİŞKİLERİ
Bir tablespace içinde bulunan Segment tipleride şu şekildedir,
13.
14. Extendlerin yönetimine şekilsel olarak bakacak olursak,
Extendlerin bir alt seviyesi olan blokları şekilsel olarak görecek olursak,
15. Datablok yönetimi iki türlü olmaktadır.Otomatik ve manuel şeklinde.
Otomatik alan yönetiminde kolay yönetim,en iyi alan sistemi,insert işlemleri için en iyi performans
sağlanır.Dikkat edilmesi gerekn LOB alanlar için bu yapı kullanılmamalıdır. PCTUSED, FREELISTS,
FREELIST GROUPS gibi yapılar otomatik kullanılır.
SQL > CREATE TABLESPACE data02
DATAFILE ‘/u01/oradata/data02.dbf’ SIZE 5M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT AUTO;
Manual alan yönetiminde ise PCTUSED, FREELISTS, FREELIST GROUPS gibi parametreler
kullanılarak yönetim yapılır.
16. PCTFREE : Tablonun her bir “data block”’unda update’ler sonucu oluşan değişiklikler için tutulan
alandır.0-99 arası değer alır, varsayılan değeri 10’dur.Yüzde “%” ile ifade edilir.”0” verilirse “data block”’un
tamamının “insert” için kullanılacağı anlamına gelir.Bu alanın değerinin seçimi önemlidir.Sık “update”
gören bir tabloda 5-10 gibi küçük değerler verilmesi “update” sonucu oluşan yeni verinin başka “data
block”lara taşınmasına sebeb olur.Bu da tabloya ulaşımda, sorgularda performans problemine yol açar.
(Boşluğun blok boyuna oranı)
PCTUSED : 1-99 arası değer alır.Varsayılan değeri 40’tır. Yüzde “%” ile ifade edilir.Bir “data block”
belirlenen pctused değerinin altına düşünce “insert” işlemi yapılmaya aday blok anlamına gelir.Mesela bu
değerimiz %40 ise “data block”’un kullanılan alan % değeri de %40 ın altına düşerse bu data block insert”
için kullanılabilir demektir.
PCTFREE ve PCTUSED parametrelerinin toplamı 100’den az olmalıdır.Tablo oluştururken her ikisi birden
kullanılbileceği gibi ayrı ayrı da belirlenebilirler.
TABLESPACE STORAGE YÖNETİM VİEWLARI
SQL > SELECT segment_name,tablespace_name,extents,blocks
FROM dba_segments
WHERE owner = 'HR';
SQL > SELECT extent_id,file_id,block_id,blocks
FROM dba_extents
17. WHERE owner='HR'
AND segment_name='EMPLOYEES';
SQL > SELECT tablespace_name, count(*),
max(blocks), sum(blocks)
FROM dba_free_space
GROUP BY tablespace_name;
UNDO YÖNETİMİ :
Undo işlemi Otomatik yada elle yapılabilmektedir.
"Automatic Undo Management" modundayken, veritabanı sunucusu tablespaceleri kullanarak undo
alanını yönetir. "Manual Undo Management" modundayken, veritabanı yöneticisi tarafından undo bilgisini
geçici olarak tutması için rollback segmentler yaratılır. Rollback segmentlerdeki bilgi veritabanının
kurtarılması sırasında kullanılır.
Parametre olarakta aşağıdaki parametresel değerler ayarlanmalıdır,
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=UNDOTBS
18. SQL > ALTER SYSTEM SET undo_tablespace = UNDOTBS;
Otomatik “Geri Alma”(Undo) Yönetimi
Otomatik geri alma yönetimi “geri alma tablo alanı” tabanlıdır. Farklı büyüklüklerde birçok geri
alma(rollback) segmentleri ayırma yerine, birkaç geri alma(undo) tablo alanları oluşturmak için alan
ayırabilirsiniz.
Otomatik geri alma yönetimi , geri alma süresini net olarak belirlenmesini sağlar. Sistem
parametresinin(UNDO_RETENTION ) kullanımı süresince kaydedilmiş geri alma bilgisinin miktarını
veritabanında tutmak için belirlenebilir. Parametreyi saat zamanı
olarak (örneğin 30 saniye) verilebilir. Süresini belirleme ile uzun sorguları başarılı bir şekilde
çalıştırabilmek için sistem yapılandırılabilir.
Geri alma alanının kullanımını daha başarılı yararlanabilmek için V$UNDOSTAT kullanarak veritabanı
sistemi görüntüleni ve yapılandırılır. V$UNDOSTAT çeşitli geri almayı ve hareketin istatistiklerini gösterir.
Örneğin Oracle anındaki(instance) geri alma alanının tüketilmiş miktarını.
UNDO_SUPPRESS_ERRORS parametresi otomatik moda elle yapılan işlemlerde oluşacak hataları
engeller.
İlk Oracle sürümlerinde, geri alma alan yönetimi geri alma segmentleri kullanılarak yapıldı. Bu yöntem
şimdi el ile geri alma yönetimi modu olarak adlandırılır.
19. Geri Alma(Undo) Modu
Geri alma modu el ile geri alma yönetiminden otomatik geri alma yönetimine geçiş yolunu daha çok esnek
olmasını sağlar. Veritabanı sistemi ya el ile geri alma yönetimi modu yada otomatik geri alma yönetimi
moduyla çalışabilir. El ile geri alma yönetimi modunda geri alma alanı geri alma segmentleri boyunca
yönetilirler. El ile geri alma yönetimi modu her uygunluk seviyesi altında desteklenir.
Otomatik geri alma yönetimi modunda geri alma alanı geri alma tablo alanları ile yönetilirler.
Otomatik geri alma yönetimi modunu kullanmak için veritabanı yöneticisi sadece her bir Oracle anı için
geri alma tablo alanı yaratması ve UNDO_MANAGEMENT başlangıç parametresine AUTO değerini
vermesi gerekir. Otomatik geri alma yönetimi modu uygunluk seviyesi oracle9i ve üstü için desteklenir. El
ile geri alma yönetimi modu desteklenmesine rağmen Oracle kesinlikle sizi otomatik geri alma yönetimi
modunu çalıştırmanızı tavsiye eder.
Geri Alma Kotası
Otomatik geri alma yönetimi modunda sistem sadece geri alma segmentlerindeki hareketlerin görevini ve
geri alma segmenti için alan ayırmayı kontrol eder. Zararlı davranışlı hareket potansiyel olarak çok fazla
geri alma alanı tüketir böylece bütün sistem felç olur. El ile geri alma yönetimi modunda geri alma
segmentlerinin büyüklüğünü küçük MAXEXTENTS değeri ile sınırlayarak böyle olasılıkları kontrol edilir.
Bununla beraber uzun çalışan hareketleri daha büyük geri alma segmentlerine SET TRANSACTION USE
ROLLBACK SEGMENT deyimini kullanarak belirgin bir şekilde atanmalıdır. Bu hantal bir yaklaşımdır.
Büyük hareketleri kontrol etmek için kaynak yöneticisi(resource manager) direktifi olan UNDO_POOL daha
belirgin yoldur. Bu veritabanı yöneticilerine her guruba maksimum geri alma alan sınırı verilen tüketici
gruplardaki kullanıcıları ile gruplara ayırmasına izin verir. Toplam geri alma alanı sınırı aşan gurup
tarafından tüketildiğinde kullanıcıları son bulan diğer üye hareketler tarafından geri alma alanı serbest
bırakılana kadar daha fazla güncelleme yapamazlar. Kullanıcılara geri alma tablo alanının geri alma
20. alanına sahip oluncaya kadar tüketmesine izin verildiğinde varsayılan UNDO_POOL’un değeri
UNLIMITED’dır. Veritabanı yöneticileri UNDO_POOL direktifini kullanarak belirli kullanıcıyı sınırlayabilir.
Geri Alma Zamanı Kontrolü
Uzun süreli çalışan sorgular bazen başarısız olurlar çünkü geri alma bilgisi tutarlı okuma işlemleri
gerektirdiği için uzun süre kullanılabilir değillerdir. Bu kaydedilmiş geri alma bloklarının aktif hareketler
üzerine yazıldığında meydana gelir.
Otomatik geri alma yönetimi geri alma alanı tekrar kullanıldığında belirgin şekilde kontrol etmek için bir yol
sağlar, yani ne kadar geri alma bilgisinin tutulacağını. Veritabanı yöneticisi UNDO_RETENTION
parametresini kullanarak peryod süresini belirleyebilir. Örneğin UNDO_RETENTION’a otuz dakika verilirse
sistemdeki bütün kaydedilmiş geri alma bilgisi en azından otuz dakikada elde edilir. Bu bütün sorguların
otuz dakika yada daha az çalışacağını garanti eder, normal şartlar altında “snapshot too old” ile
karşılaşmamanız gerekir.
UNDO_RETENTION ya başlangıçta belirleyebilirsiniz yada ALTER SYSTEM deyimiyle dinamik olarak
değiştirilir. Aşağıdaki örnekte tutma süresi yirmi dakikaya belirlenmiştir;
SQL > ALTER SYSTEM SET UNDO_RETENTION = 1200;
UNDO_RETENTION parametresini belirlemezseniz Oracle sorguları genelde çok büyük olmayan birçok
OLTP sistemlerine yetecek kadar küçük varsayılan değer kullanır.
Genelde tutma süresini geri alma tablo alanını destekleyebilecek yakın bir değerle belirlenmesi iyi bir fikir
değildir, çünkü geri alma segmentleri arasındaki alanın gereğinden fazla hareketi sonuç olabilir. Geri alma
alanı olarak tamponun 20%’si tavsiye edilir.
SCN
SCN (System Change Number) Oracle ‘in yine recovery icin kullandigi onemli bir mekanizmadir. Bir
transaction commit edildiginde Oracle veritabaninin o anki durumunu yani o andaki consistent(tam ve
dogru) durumunu belirten internal timestamp seklinde bir unique numara atamasi yapar bu SCN dir.
SCN hem unique hem ardisil artan seri bir numaradir. SCN veritabaninin read consistent goruntusunu
saglamak icin de kullanilir. Bu anlamda veritabani her zaman SCN bazinda da recovery edilebilir. Bir query
Execution asamasina gediginde o an gecerli olan bir SCN atamasi yapilir ,atanan bu SCN den kucuk veya
esit olan SCN lere sahip olan ilgili tum data block larin yanlarina yeni SCN numarasi konur ve guncellenir.
Ilgili transaction’u ilgilendiren bu data block bilgisi UNDO bolgesinden elde edilir.
Olusan bu yeni SCN numarası control file’a yazilir, data file header lara update edilir ve redo log file ‘ada
bu SCN yazilir.
Server Process commit işlemi yapıldıgında bir SCN olusturur ve bunu rollback (Undo) segment’e
bildirir.Sonra Rollback segment’te transaction’un commit edildigi bilgisi verilir ve artik Undo ya ihtiyac
kalmadigi anlasilir.
21. LGWR redo log buffer daki bilgileri diskteki Online Redo Log File’a ilgili bu SCN numarasi ile yazar.Yani
commit ile diskte kayitlar atilmis demek degildir ancak Redo bufer dan Redo Log file lara aktarmak
demektir ki bu da bir nevi bilgilerin korunmasi anlamina gelmektedir)
Redo Log filelar en dusuk ve en yuksek SCN numara bilgisine sahiptir. Yani en kucuk change number ve
guncel redo log file kapanipta yenisi acilmadan onceki atanan en buyuk SCN number bilgisi ilgili Redo Log
file da bulunur.
Ayrıca ne zamanki chekpoint olupta bilgiler update oldugunda bu SCN bilgisi ilgili data file header da
saklanir. Control file ise yapisal her degisikligi sembolize eden her SCN degisim bilgisini de kaydeder.
UNDO TABLE SPACE OLUŞTURMA
Database oluşturulurken default olarak undo vermek mümkündür,
SQL> CREATE DATABASE db01
...
UNDO TABLESPACE undo1 DATAFILE 'undo1db01.dbf'
SIZE 20M AUTOEXTEND ON
Yada daha sonrası için tekrar bir undospace oluşturmak ta mümkündür.
SQL> CREATE UNDO TABLESPACE undo1
DATAFILE 'undo1db01.dbf' SIZE 20M;
Mevcut bir undo tablespace e yeni bir datafile eklemek te aşağıdaki gibidir.
SQL> ALTER TABLESPACE undotbs
ADD DATAFILE 'undotbs2.dbf' SIZE 30M
AUTOEXTEND ON;
Aşağıdaki komutlada undo görevini başka bir tablespace e verebiliriz.
SQL> ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2;
22. Mevcut bir undotablespace i bildiğimiz komutlar ile drop edebilmekteyiz.Ama dikkat etmemiz gerekn drop
ettiğimizin aktif undotablespace olmamasıdır.
SQL> SELECT a.name,b.status
FROM v$rollname a, v$rollstat b
WHERE a.name IN ( SELECT segment_name
FROM dba_segments
WHERE tablespace_name = 'UNDOTBS'
)
AND a.usn = b.usn;
Daha sonrada drop diyerek silebiliriz.
SQL> DROP TABLESPACE UNDOTBS2;
Undo istatistilerini almak istiyorsak aşağıdaki sorguyu kullanabiliriz.
SQL> SELECT end_time,begin_time,undoblks
FROM v$undostat;--Undo istatististikleri
END_TIME BEGIN_TIME UNDO
------------------ ------------------ ----22-JAN-01 13:44:18 22-JAN-01 13:43:04 19
22-JAN-01 13:43:04 22-JAN-01 13:33:04 1474
22-JAN-01 13:33:04 22-JAN-01 13:23:04 1347
22-JAN-01 13:23:04 22-JAN-01 13:13:04 1628
22-JAN-01 13:13:04 22-JAN-01 13:03:04 2249
22-JAN-01 13:03:04 22-JAN-01 12:53:04 1698
22-JAN-01 12:53:04 22-JAN-01 12:43:04 1433
22-JAN-01 12:43:04 22-JAN-01 12:33:04 1532
22-JAN-01 12:33:04 22-JAN-01 12:23:04 1075
UNDO SİZİNG
Sizing olarak ne kadar undo harcanıyor,yük nedir gibi bilgileri çalıştıracağımız sorgular ile görmek
mümkündür.
23. --(UR) UNDO_RETENTION değeri
--(UPS) Saniyede oluşan undo bloklarının sayısı
--(DBS) (db_block_size)
UndoSpace = [UR * (UPS * DBS)] + (DBS * 24)
SQL> SELECT (SUM(undoblks) / SUM( ((end_time - begin_time) * 86400)))
FROM v$undostat;--UPS HESAPLAMASI
Undo Space Aşağıdaki gibi de hesaplanabilir.
SQL> SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"
FROM (SELECT value AS UR
FROM v$parameter
WHERE name = 'undo_retention'),
(SELECT (SUM(undoblks)/SUM(((end_time begin_time)*86400))) AS UPS
FROM v$undostat),
(SELECT value AS DBS
FROM v$parameter
WHERE name = 'db_block_size');
DBA_ROLLBACK_SEGS view ı ile mevcut rollback segmentler görüntülenebilir.
SQL> SELECT segment_name,owner,tablespace_name,status
FROM dba_rollback_segs;
Segmentlerin kullanım bilgiside aşağıdaki sorgu ile görüntülenebilir.
SQL> SELECT n.name, s.extents, s.rssize,s.hwmsize,
s.xacts, s.status
FROM v$rollname n, v$rollstat s
WHERE n.usn = s.usn;
Materialized Views
24. Kullanım amacı Uzak veritabalarındaki tabloların birebir görüntüleri yada lokal veritabalarında kullanılan
tablolar üzerinde hesaplama işlemlerini tutmak için kullanılır.En büyük Avantajı çok hızlıdırlar.Ve yeniden
oluşma süreleri olağünüstüdür.Genellikle Data Wharehouse porojelirnde kullanılırlar.
SQL> CREATE MATERIALIZED VIEW mv_emp_pk
REFRESH FAST START WITH SYSDATE
NEXT SYSDATE + 1/48
WITH PRIMARY KEY
AS SELECT * FROM emp@remote_db;
Materialized view created.
Yukarıda SQL SYSDATE + 1/48 zaman süresinde refresh olan primary key alanına göre yaratılmış bir
viewdır.
Fast optionu yarattıktan sonra remote tarafta aşağıdaki cğmleyi çalıştırmak zorundayız.
SQL> CREATE MATERIALIZED VIEW LOG ON emp;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW mv_emp_rowid
REFRESH WITH ROWID
AS SELECT * FROM emp@remote_db;
Yukarıdaki view ise rowid alanına göre refresh olan bir viewdır.
SQL> CREATE MATERIALIZED VIEW mv_empdept
AS SELECT * FROM emp@remote_db e
WHERE EXISTS
(SELECT * FROM dept@remote_db d
WHERE e.dept_no = d.dept_no)
Yukarıdaki view ise subquery mantığında yaratılmış bir viewdır.
SQL> CREATE MATERIALIZED VIEW
depart_sal_sum as
select d.department_name, sum(e.salary)
25. from departments d, employees e
where d.department_id = e.department_id
group by d.department_name;
Yukarıdaki view ise local tabanlı summary işlemi yapan bir viewdır.
MV leri istersek aşağıdaki komutlarla da manuel olarak refresh edebiliriz.
SQL> DBMS_MVIEW.REFRESH
(’CUST_SALES’, parallelism => 10);
SQL> DBMS_MVIEW.REFRESH_DEPENDENT(’SALES’);
SQL> DBMS_MVIEW.REFRESH_ALL_MVIEWS;
Ana tablodan oluşan MV nin yeniden yapılanabilmesi için öncelikle QUERY_REWRITE_ENABLED
parametresinin true yapılması gerekir.