Windows Nesne Denetlemeyi Etkinleştirme

Öncelikle yerel güvenlik ilkesinden nesne denetim ilkesinin etkinleştirilmesi gerekiyor. Bu işlemi yapmak için
çalıştır'a secpol.msc yazabilirsiniz.

Denetlenecek Nesnelerin Belirlenmesi

Hangi klasörün kimler için denetleneceği klasörün güvenlik ayarlarından yapılıyor.

Windows Olay Görüntüleyici İle Logları İnceleme

bu ayarlar yapıldıktan hemen sonra windows olay görüntüleyicisinde Güvenlik klasörü altında tüm denetleme loglarını görebilirsiniz. Bunlarda bir hayli var ve bir şekilde işlenmesi gerek.

PowerShell ile Logları İşleme

Aşağıda yazdığım script ile loglarda geçen dosya isimleri ve kaçar adet geçtiklerini tespit ediyoruz.

 
function  get-objectname($msg)
{
  #Log Mesajından nesne adını çıkaran fonksiyon
    $pattern = [regex] "(Object Name|Nesne Adı)([:])(\s)(.*)";
    $match = $pattern.match($msg);
    if($match.Success)
    {
       return $match.Groups[4].value;
    }
    else
    {
      return "İsim Alınamadı";
    }
}
 
$events = (Get-EventLog Security -EntryType SuccessAudit -InstanceId 4663  -Source Microsoft-Windows-Security-Auditing) ;
 
$hashlist = New-Object 'System.Collections.Generic.Dictionary[string,int]';
 
$hashlist.Clear();
 
$mindate = [datetime]::Now;
#tüm olay loglarını inceleyen döngü
foreach($e in $events)
{
   if($e.TimeGenerated -lt $mindate)
   {
     $mindate =  $e.TimeGenerated;
   };
  $objectname = get-objectname($e.Message);
  $hashlist[$objectname] += 1;
}
#toplam kaç log girdisi incelendiğini çıktıya ekle
$hashlist["Toplam İncelenen"] = $events.Count;
#GridView için pencere başlığı
$title = $mindate.tostring()+ " Tarihinden Beri Ençok işlem gören dosyalar";
#1 defadan daha çok loglarda geçen dosya isimlerini kullanılma sayısına göre ters sırala
$result = ($hashlist.GetEnumerator() | where {$_.value -gt 1} | sort -property Value -descending );
#çıktıyı grid form olarak göster
$result | Out-GridView  -Title $title;
 

PowerShell Out-GridView ile listenin görünümü.Bu ekranda filtreleme ve sıralama yapılabiliyor olması çok hoş.

Herşey boyutu yaklaşık 300GB olan bir tabloyu dışa aktarmak istememizle başladı. Export işlemi her denememizde
"ORA-01555 Snapshot Too Old" hatasıyla iptal ediliyordu. Önce sorunun çok uzun süren sorgulardan olabileceğini düşündük ve
UNDO TABLESPACE alanını genişlettik ve UNDO_RETENTION parametresinin değerini yükselttik. Sonra tekrar denedik ve yine aynı hatayı aldık. Sonunda sorunun LOB alanların bozulmasından kaynaklanabileceğini söyleyen bir makale okudum ve aşağıdaki işlemleri yaparak bozuk olan LOB alanlarını içeren satırları tespit ettik.

Lob Corruption Tespit Edilmesi

 
 CREATE TABLE corrupt_lobs (corrupt_rowid rowid, err_num number);
 

Önce yukardaki şekilde ilgli satırları kaydedeceğimiz bir tablo oluşturuyoruz. Daha sonra
Lob içeren tablomuzun tüm kayıtlarını dönecek olan şu script çalıştırıyoruz.

 
declare
  error_1578 exception;
  error_1555 exception;
  error_22922 exception;
  pragma exception_init(error_1578,-1578);
  pragma exception_init(error_1555,-1555);
  pragma exception_init(error_22922,-22922);
  n number;
begin
  FOR cursor_lob IN (SELECT rowid r, IMAGE FROM IMAGE_TABLE) loop
  begin
    n:=dbms_lob.instr(cursor_lob.belge,hextoraw('889911'));
  exception
    when error_1578 then
      INSERT INTO corrupt_lobs VALUES (cursor_lob.r, 1578);
      commit;
    when error_1555 then
      INSERT INTO corrupt_lobs VALUES (cursor_lob.r, 1555);
      commit;
    when error_22922 then
      INSERT INTO corrupt_lobs VALUES (cursor_lob.r, 22922);
      commit;
    end;
  end loop;
end;
/
 

Bu PL/SQL script işlemi tamamladıktan sonra corrupt_lobs tablosuna baktığınızda bozulmuş olabilecek LOB değerlerini içeren satırları görüyoruz.

Artık bu satırları silermisiniz yoksa LOB alanları EMPTY_LOB olarakmmı ayarlarsınız size kalmış.

Biz bu satırları sildiğimizde EXPORT başarı ile sonuçlandı.

Bir sunucudan diğerine verileri taşımanın en hızlı yolu DataFile kopyalama işlemidir. Sunucuları taşırken Full export ve import yapmak yerine bu yöntemi kullanmak çok daha kısa sürecektir.
Bu yöntem kullanıldığında DataPump Export (expdp)sadece yapısal bilgileri(meta data) içeren bir DUMP dosyası üretir. Bu işlemi yapabilmek için TRANSPORT_TABLESPACES parametresi kullanılır. Bu işlem bittikten sonra import sırasında hem DUMP dosyasına hem de ilgili veri dosyalarının(Data Files) kopyalarına ihtiyacınız olacaktır.

Export öncesi yapılacak işlemler ve kontroller

1- Kaynak veri tabanı ile hedef veri tabanının karakter setleri aynı olmalıdır.
2- Hedef veri tabanı oracle sürümü kaynakla aynı veya daha üst sürüm olmalıdır.
3- Aktarılacak olan tablo alanı(Tablespace) Read Only olmalıdır.
4- Export işlemini yapacak olan veri tabanı kullanıcısı EXP_FULL_DATABASE role yetkisine sahip olmalıdır.
5- Import işlemi yapacak olan veri tabanı kullanıcısı IMP_FULL_DATABASE role yetkisine sahip olmalıdır.
6- Aktarılacak tablo alanı, işlemi yapan kullanıcının varsayılan tablo alanı (DEFAULT TABLESPACE) olamaz.
7- Şifrelenmiş sütunlar (Exncrypted columns) bu yöntemle aktarılamaz.
8- SYS ve SYSAUX tablo alanları bu yöntemle aktarılamaz.

Bu kadar teorik bilgiden sonra örneğimize geçelim.

Örnek

Srv1 ve srv2 isimli iki sunucumuz var. Bunlardan srv1 kaynak srv2 ise hedef veri tabanı sistemi.
SRV1 sunucusunda şu şekilde bir tablo alanımız var.

CREATE TABLESPACE tbs1 DATAFILE   '/data/tbs1.DBF' SIZE 4G AUTOEXTEND ON ;

Her iki sunucuda da /data ve /ydk isimli klasörler bulunsun ve şu şekilde bir directory olsun.
Create directory ydk as ‘/ydk/’;
İşlemlerimiz şu şekilde olacak.

• Export(SRV1 sunucusunda)
o Alter tablespace tbs1 read only;
o Expdp system/password directory=ydk dumpfile=tbs1.dmp transport_tablespaces=tbs1 logfile=transport.log
• Kopyalama(SRV1 sunucusunda)
o Tbs1.dmp dosyasını hedef veri tabanı sunucusunda /ydk klasörüne kopyala
Scp tbs1.dmp srv2:/ydk
o Tbs1.dbf isimli veri dosyasını hedef veritabanı sunucusunda /data klasörüne kopyala
Scp /data/tbs1.dbf srv2:/data

• Import (SRV2 sunucusunda)
o Impdp system/password directory=ydk dumpfile=tbs1.dmp TRANSPORT_DATAFILES='/data/tbs1.dbf'

Bu şekilde TBS1 isimli tablespace olabilecek en hızlı yöntemle srv1 sunucusundan srv2 sunucusuna taşınmış oldu.

Bu işlemi NETWORK_LINK parametresini kullanarak ta yapabilirdik. Bence bu hali daha kullanışlı.

Linux'da tırnak karakterine escape eklemeniz gerekebilir. yani ' yerine \' yazmanız gerekebilir veya parameterfile kullanarakda bu sorunu çözebilirsiniz.

Eğer transfer edilecek tablespace ASM üzerinde bulunuyorsa datafile kopyalamak için asmcmd kullanabilirsiniz. ASM ile ilgili yazımı ilişkili linkler bölümünde görebilirsiniz.

Bu örneğin işinize yarayacağını umarım.

SQL*Loader harici dosyalardan veri tabanındaki bir tabloya veri almak için kullanılan bir araçtır.

Bu aracı kullanarak metin  dosyası olarak aldığınız veriyi hızlı bir şekilde ayrıştırıp(parsing) bir veya birden fazla tabloya taşıyabilirsiniz(import). SQL*Loader  ile LOB  veri türündeki(resim,video,doküman,vb.) verileri de tablolarınıza aktarabilirsiniz.

Bu yazımda BLOB veri içeren bir tablonun kayıtlarını TOAD ile dışarı aktarıp  SQL*Loader  kullanarak başka bir veri tabanına taşımanın yolunu gösteren bir örnek vereceğim.

TOAD Quest Software tarafından piyasaya sunulan SQL-PL/SQL geliştirme aracı ve bir birinden faydalı DBA araçları sunan güçlü bir yazılımdır.

Export LOB Data

 
CREATE TABLE personel
 
(
id varchar(10) NOT NULL,
ad_soyad varchar(40) ,
dogumtar date,
resim blob
)
 

Örnek tablomuzun yapısı yukarda görüldüğü gibidir. Öncelikle Tablomuzun BLOB verilerini dışa aktaralım.

Yukardaki şekilde Toad SQL Editörde sorgumuzu çalıştırıyoruz. Sorgu sonuçlarını gösteren grid üzerinde sağ tıklıyoruz ve gelen menüden Export (Longs,Raws ..) menüsünü tıklıyoruz.

Karşımıza yukardaki gibi Single Column Export formu geliyor. Dışa aktarılacak kolon olarak BLOB veri içeren kolonu, Export path olarak dışa aktarılan resimlerin kaydedileceği yolu  seçiyoruz. Dışa aktarılan dosyaların isimlerinin ID alanındaki değerlerle aynı olması için File Extension metin kutusunu boşaltıp ilgili yerlerden ID alanını seçiyoruz.  OK butonuna tıklayarak dışa alma işlemini başlatıyoruz.

Şimdi tablodaki diğer alanları aktarmaya geçebiliriz.

Bir kez daha sorgu sonuçlarını gösteren grid üzerinde sağ tıklıyoruz ve gelen menüden

“Export to flat file …“ komutu veriyoruz.

Karşımıza Flat File Export From Query  ekranı geliyor.  Bu ekranda

1-      Option sekmesinden To-File seçeneğini seçerek  veri dosyasını nereye kaydedeceğimizi seçiyoruz.

2-      Spec file sekemesinde Generete Columns butonuna tıklayarak sütün tanımlarının oluşmasını sağlıyoruz.

3-      SQL Loader Sekmesinden yapmak istediğimiz işlemi(Append,Insert,Truncate…)  ve diğer SQL*Loader seçeneklerini seçiyorur. (Insert:Kayıtları boş bir tabloya aktarmak, Append: Kayıtları tabloya ekletmek ,Truncate: Tabloyu boşalttıktan sonra aktarma işlemini başlatmak)

4-      SQL Loader sekmesinde  otomatik olarak oluşan metni şu şekilde değiştiriyoruz metni şu şekilde değiştiriyoruz

RECOVERABLE
LOAD DATA
INFILE "C:\Users\Administrator\Desktop\sqlloader\data.txt"
APPEND INTO TABLE  PERSONEL
( ID POSITION (1:10) CHAR,
AD_SOYAD POSITION (12:51) CHAR,
DOGUMTAR POSITION (53:71) DATE (19) "MM/DD/YYYY HH24:MI:SS",
RESIM lobfile(id) terminated by EOF
)

Burada APPEND INTO TABLE ifadesinden sonra verileri aktaracağımız tablonun adını yazıyoruz ve metinin sonuna eklediğimiz ",RESIM lobfile(id) terminated by EOF " ifadesi ile RESIM alanının değerlerinin ID alanının değeri ile aynı isimdeki dosyalardan aktarılacağını belirtiyoruz.

5-      Bu düzenlemelerden sonra SQL Loader sekmesindeki kayıt butonu ile SQL Loader control file dosyamızı kaydediyoruz. Ben örneğimde bu dosyayı adını personel.ctl olarak kaydettim.

6-      Execute butonuna tıklarak verilerin dışa aktarılması işlemini başlatıyoruz.

Import Lob Data

Verileri içe aktarma işlemini başlatmak için aşağıdaki komutu girerek SQL*Loader’ı başlatabilirsiniz.

sqlldr hbys@orcl control=personel.ctl

Bunun yerine TOAD SQL Loader Wizard’ı da kullanabilirsiniz. Bu sihirbazı başlatmak için Database->Import menüsünün altına bakınız ve Toad Options da executables kısmına bakarak,sql loader exe dosyasının ayarını kontrol ediniz.

İstemci ile sunucu arasındaki bağlantı düzgün bir şekilde sonlandırılmadığında(örneğin ağ problemleri,ağ kablosunun çıkması,uygulamanın kırılması vs..) istemci tarafında bağlantı ölmesine rağmen sunucu tarafında ilgili oturum hala sunucu kaynaklarını kullanmaya devam edebilir. Tabikide bu durum bağlantı sayısına göre özellikle DEDICATED sunucularda önemli bir sorun haline gelebilir.

Oracle SQLNET.ORA dosyasında bir parametre değişikliği ile Dead Connection Detection özelliği etkin hale getirilebilir.

DCD Etkinleştirme

SQLNET.ORA dosyası $ORACLE_HOME/network/admin klasöründe bulunur.
SQLNET.ORA dosyasında
SQLNET.EXPIRE_TIME=#dakika#
parametre değerini ayarlamak yeterlidir. Bu değer varsayılan olarak belirtilmemiştir ve SQLNET.ORA dosyanızda böyle bir parametre olamayabilir.

Bu parametre için tavsiye edilen değer 10 Dakikadır.
Oracle PMON Bu parametrede belirtilen aralıklarla tüm istemcilere bir paket gönderir ve cevap bekler cevap alınamayan istemcilerin sunucu tarafındaki processler öldürüler ve kullandıkları kaynaklar serbest bırakılır.

Bu özelliği açmak listener servisine ek maliyet getir.

Daha fazla bilgi için
burayı tıklayınız.

Burayı tıklayınız.

Gruplardan askerliği seçerek sorulara ulaşabilirsiniz.
Bu sayfada bir kaç soruda sizin eklemenizi bekliyorum.

dotnetfx35.exe İNDİR

WindowsInstaller-KB893803-v2-x86 İNDİR

Scada Citect Part 1 İNDİR

Scada Citect Part 2 İNDİR

Scada Citect Part 3 İNDİR

Scada Citect Part 4 İNDİR

Scada Citect Part 5 İNDİR

Scada Citect Part 6 İNDİR

NOT: Dosyaları indirdikten sonra zip dosyalarını Citect 7.20 dosyasının içerisine açın ve "setup.exe" tıklayınız...!

Symbol Factory 2.0

Sembol Programı İNDİR

Citect Scada Eğitim Linkleri

Citect Scada Kitabı (pdf) İNDİR

Citect Scada Eğitim Videoları En Kısa Zamanda Eklenecektir...!

Supervisory Control And Data Acquisition

SCADA sistemleri için veri yolları farklı firmaların ürettiği farklı ürünler ve iletişim protoklleri ile günümüzde mühendislik zamanı açısından önemli bir dezavantaj oluşturmaktadır. Bunun farkına varan yazılımcı firmalar ise aynı andan birkaç protokolü destekleyen yazılımlar ortaya çıkarmışlardır. Bunun için ise ağ üzerine uygunlaştırıcı modüller ekleme zorunluluğu doğmuştur. Dolayısı ile günümüzde bir SCADA sistemi için tek bir veri yolu yapısından söz etmek neredeyse imkansız hale gelmiştir. Veri iletişimi konusunda yapılacak bir seçimin Ethernet yönünde yapılmasıyla sağlanan en büyük Avantaj ekonomidir. PC, Windows ve Internet teknolojilerinde standart bir bileşen olan ethernet teknolojisi yüksek veri hızlarında düşük maliyetle çalışabilmektedir. Kullanıcılar seçtikleri teknolojinin şu anki ve gelecekteki gereksinimlerini karşılayacağından emin olmak isterler. Doğal olarak hiçbir mühendis on yıl sonra bu gün kullandıkları ürünlerin piyasadan kalktığını veya ağ artık üzerindeki yükü taşıyamadığı için bütün iletişim sistemini yenilemek zorunda kalmayı istemez. Ancak ne yazık ki üreticiler arasındaki çekişmelerin standartlaşmayı geciktirdiği ve son kullanıcıların asıl gereksinimlerini karşılama konusunda başarısızlığa yol açtığı da bir gerçektir.

Sensörleri denetim uygulamalarını tek bir ağ yapısında toplamak isteyen şirketler çok az seçenek ile karşılaşmaktadırlar. Bunun için DeviceNet, CAN Bus, Profi Bus, ControlNet, Foundation Fieldbus.. gibi birkaç iletişim ağı teknolojisi vardır ve bunların her birinin üreticisi en iyi seçimin kendileri olacağını iddia ederler. Bunlardan hangisini seçmenin daha yararlı ve ekonomik olacağı yanıtlaması çok güç bir sorudur. Bunların hemen hepsi bir veya birkaç üreticinin özel ihtiyaçları göz önüne alınarak tasarlanmıştır. Örneğin ProfiBus'ın geliştirilmesinde Siemens ve Klockner-Moeller etkili olurlarken, Allen-Bradley ControlNet'i kendi PLCleri için geliştirmiştir. Öte yandan Foundation Fieldbus geleceğin veri yolu olarak, pek çok sistemle uyumluluk göz önüne alınarak tasarlanmaktadır. Foundation Fieldbus on yılı aşkın zamandır geliştirilme aşamasındadır ve bazı politik çıkarlar bu sistemin geliştirilmesini yavaşlatmıştır. Bütün bu olumsuz gelişmelere rağmen pazarın daralarak bütün üreticilerin destekleyeceği bir veya iki standart ağ teknolojisi ile sınırlanmasına sebep olacağına kesin gözüyle bakılmaktadır. Bu, PC'nin bilgisayar pazarını ele geçirmesinin hikayesine benzeyebilir.

PC ortamının açık sistem mimarisi neredeyse hayal edilebilen bütün sistemlerin kurulumuna olanak sağlamaktadır. Endüstriyel sistem tasarımcılarının değişik üreticilerden aldıkları ekipmanları benzeri bir açık mimari kullanarak bir arada ve sorunsuzca kullanabilme beklentilerini ve talepleri her gün artmaktadır. İşte bu noktada var olan sensör ağlarının içerdiği karmaşık iletişim tekniklerine alternatif olarak ethernet adıyla yeni bir iletişim teknolojisi yaratılmıştır..
PC'yi endüstriyel pazara sokmayı başaran ekonomik sebepler şimdi de ethernet için geçerlidir. Win 9x.2000, NT ve Unix, ortamında yıllardır bir standart olan TCP/IP protokolü bütün verinin gönderilmesini garantileyen bir yapıya sahiptir ve günümüzde işletmelerin neredeyse tümünde bilgi akışı için en güçlü seçenektir. Ethernet, şu an var olan bütün endüstri standardı PC donanımları ve işletim sistemleri ile uyumludur.

Bir başka önemli nokta da kurulum ve bakım masraflarıdır. Burada da Ethernet diğer bütün alternatiflere karşı bir hayli avantajlı konumdadır. Ethernet'in kablolama özellikleri onun kurulumunu ve genişlemesini çok kolaylaştırmaktadır. Yapıya eklenen ucuz hublar, sisteme yeni birimler eklemeyi basitleştirirler. Bir cihazı yeni yerinde tekrar ağa bağlamak için yapılması gereken tek şey en yakınındaki hub'a bir 10Base-T kablosu çekmektir. Özelleşmiş ağ yapılarında eğitim ve bakım maliyetleri çoğu zaman hatırı sayılır miktarlara ulaşmasına rağmen eternet sisteminin bakımı var olan işletme personelince sorunsuz olarak yapılabilir Ethernetin 10-Mbps ve 100-Mbps versiyonları dağıtık I/O sistemleri için yeterli bir bant genişliği sunmaktadır.10Base-T bile 19.2 Kbaud tipik bir RS422/485'den çok daha hızlıdır. Bant genişliğinin büyük olması, özellikle pekçok sinyalin aynı anda gözlendiği uygulamalarda olaylara hızlı cevap verme anlamına gelir. 1997'de geliştirilen 100Base-T ile 100 Mbps transfer hızı ile şu an var olan en yüksek performanslı rakibinden bile 10 kat daha hızlı ve o oranda ucuz hale gelmiştir. Son olarak, 1998'de IEEE 802.3z standardının kabulü ile Ethernet için artık 1000 Mbps hızlardan söz edilmektedir. Bu yeni standart "Gigabit Ethernet" diye tanımlanmaktadır . Bu yeni standardın önemli özelliklerinden bir tanesi kurulu bulunan 10Base-T ağlarla uyumluluğudur.

Pekçok uygulama genel olarak çeşitli sensörlerden gelen verinin izlenmesini gerektirir. Makina veya süreçlerin izlenmesi, alarmların, arızaların, proses değişkenlerinin kaydedilmesi bu sınıfa dahil edilebilir.Bir diğer uygulama alanı ise özellikle insan bulunmayan ortamlardaki çevre koşullarının izlenmesi ve kontrolüdür. Bu uygulamalar veriyolu üzerinde çok fazla bir yük oluşturmaz. Ağın yalnızca veriyi hızlı ve güvenli bir şekilde iletmesi gereklidir. Bütün veri iletildiği sürece determinizm ve mesaj önceliği gibi sorunlar çok önemli değildir. Yüksek veri transfer hızı, güvenilir veri iletimi ile bir TCP/IP Ethernet sistemi bu tür uygulamalar için son derece uygundur. Başka hiçbir veriyolu hız; maliyet ve kurulum kolaylığı konusunda Ethernet ile rekabet edemezDenetim uygulamaları için sistemler tasarlarken bazı farklı gereksinimler vardır. Bu sistemler öngörülebilir tepkiler vermeli, veriyolu belirli süre içinde bir veri paketini gideceği yere ulaştırmalıdır. Bu tür uygulamalarda alışıldığı üzere çoğu zaman bir sensörden gelen bilgilere göre herhangi bir olayın gerçekleşmesi gerekir. Denetim uygulamaları için token-passing metodu kullanarak veri paketleri arasında çarpışmayı engelleyen ProfiBus gibi veriyolları geliştirilmiştir. veri çarpışması Ethernet üzerinde iki cihaz aynı anda bilgi göndermeye kalkıştıklarında gerçekleşir. Tabii ki bu öngörülebilirliğin de bir bedeli vardır. Diğer veri yollarında sistem elemanları pahalıdır, kullanılan protokoller özeldir, bütünleşme zordur ve tecrübeli programcılara gereksinim vardır. ( Her nekadar Ethernette veri çarpışması olasılığının var olduğu ve bu nedenle bazı uygulamalar için güvensiz bir teknoloji olduğu düşünülsede yüksek ekonomik avantajları, kanıtlanmış başarısı, açık mimari yapısı onu sahadaki veri toplama sistemleri ile işletmedeki geri kalan diğer cihazlarla birleştirmek için yaygın bir ağ çözümü haline getirmiştir.

Özel ağ yapılarının yüksek maliyetlerinin yanısıra bütün fabrikada tek bir ağ standardına duyulan ihtiyaç Ethernetin yaygınlaşmasında çok önemli rol oynamıştır. Eğilim ilk olarak Ethernet'in Foxboro, SquareD, Westinghouse gibi bazı proses denetimi ve PLC firmalarınca kontrol seviyesinde kullanılması ile başladı. General Motors ise şu anda otomotiv endüstrisinde yaygın olarak kullanılan yeni bir yaklaşımın öncüsü oldu: Open Modular Architecture Controller. Bu yaklaşım Ethernet üzerinden PC-tabanlı denetimi desteklemektedir. Ethernet'in dev tabanı, bu standardın ilerideki uygulamaların da altından kalkabilecek şekilde geliştirileceğinin ve destekleneceğinin bir göstergesidir. IEEE komitesi Ethernet standardını çeşitli revizyonlardan geçirmiştir. Örneğin, IEEE 802.3x full duplex spesifikasyonu 1997'de ortaya çıkmıştır. Bu twisted-pair veya fiber optik kablo üzerinden standart Ethernet veri paketlerinin çift yönlü olarak aynı anda alınmasına ve gönderilmesine olanak tanımaktadır. Bu standardın kullanılması bant genişliğini iki katına çıkarırken, veri çarpışması olasılığını da en aza indirmektedir.

Bir diğer önemli standart ise IEEE 802.1p dir ve mesaj önceliğine sahiptir.100Base-T gibi daha hızlı teknolojiler veri çarpışması olasılığını azaltsalar da bu standart, öngörülebilirliğin hayati olduğu uygulamalarda bu olasılığı tamamen ortadan kaldırmaktadır. 802.1p'nin uygulanması ile kullanıcılar mesajlara öncelik sırası atayabilir ve bazı kritik mesajların cevap süresi kesin olarak belirlenebilmektedir. Son yıllarda birçok Ethernet tabanlı veri toplama sistemi piyasaya çıkmıştır, Belli başlı DAC, RTU ve PLC üreticileri Ethernet arabirimleri sunmaktadırlar. Endüstriyel otomasyon alanında çalışan pekçok uzmana göre Foundation FieldBus'ın kontrol seviyesi H2 spesifikasyonlarının 100Base-T Ethernet tabanlı olacağı öngörülmektedir. Bu uzmanlara göre Internet teknolojilerinin daha da etkili olmaları, ve endüstriyel otomasyon pazarında büyük değişikliklere yol açmaları öngörülmektedir. Yakın gelecekte bir Web browser üzerinde Java veya Dynamic HTML kullanarak bütün çalışma bilgilerini yayınlayacak endüstriyel cihazların çıkması beklenmektedir. Sahadaki her cihaz bir homepage'e sahip olacak ve bu sayfadan konfigürasyon ve çalışma bilgilerini izlemek her zaman mümkün olacaktır. Sahadaki cihazlardan gelen veri çok değişik formatlarda görsellenerek verilerin ağ üzerinde "canlı" hale gelmesi sağlanacaktır. Bu fabrika içindeki ağla bilgi alışverişinde bulunan her cihazın bir IP numarasına sahip olmasını ve TCP/IP protokolünde haberleşmesini gerektirecektir. Doğru Firewall korulması ile bu bilgiler yalnızca yerel olarak değil Internet erişimine sahip her yerden izlenebilir hale gelecektir. Kuşkusuz bu eğilimlerin sonucu olarak, otomasyon sistemlerinin mimarisi ağın yapısına bağlı olarak belirlenecektir.
Sırası gelmişken RTU lardan bağımsız olarak kullanılan diğer haberleşme protokollarından
da kısaca bahsedelim:

• RS232 : En eski, en basit, en yaygın ve en çok bilinen iletişim protokolüdür.
• RS485 : RS232'nin mesafe yönünden oluşturduğu dezavantajı azaltmak için geliştirilmiş protokoldür.
• USB : Kısa mesafe ve hızlı veri iletişimi ile günümüzdeki PC bazlı donanım veya aparat üreten firmaların hemen hemen hepsince desteklenen iletişim protokolüdür.
• GPIB : Hızlı ve güvenilir veri iletimi için geliştirilmiş bir iletişim protokolüdür.
• PROFIBUS : Profibus geniş kapsamlı üretim ve proses otomasyonu için tasarlanmış üreticiden bağımsız açık saha bus standartıdır. Üretici bağımsız oluşu ve açıklığı uluslararası standartlar olan En 50170, EN 50254 ve IEC 61158 üzerine kurulmuştur. 650'ye yakın üyesi bulunan ve birçok araştırma enstitiüsü tarafından desteklen Profibus, farklı üreticilerin cihazları arasında haberleşme sağlayan ve bunu yaparken herhangi özel bir arabirime ihtiyacı olmayan bir veri yolu olmakla birlikte, yüksek hızlı kritik uygulamalar veya komplex haberleşme işlemleri gibi kullanım alanlarında yaygın olarak uygulanan bir veri yolu sistemidir.
• CAN BUS : Bosch firması tarafından geliştirilen (seri) veri yolu sistemi olan Controller Area Network veri yolu sistemi, özellikle otomotiv sektörüne yönelik akıllı network sensör ve actuatörler için tasarlanmış ve kısa bir zamanda bu çalışmalarda standart hale gelmiştir. Multi-Master yani bütün CAN noktalarının data iletebildiği ve birkaçınıda eş zamanlı olarak istekte bulunabildiği veri yolu sistemi olan CAN hiçbir abone ya da kullanıcı için herhangi bir adreslemeye sahip olmamakla birlikte öncelikli mesajın iletilmesi şeklinde veri iletir. Bu veri iletişim protokolu en sık Otomotiv ve Medikal endüstrisinde kullanım alanı bulmaktadır.
• DEVICENET : Allen-Bradley tarafından geliştirilen Akıllı sensör ve aktüatorler için tasarlanmış endüstriyel network yapısı olan DEVICENET "Open DeviceNet Vendors Association " adı verilen üretici bağımsız bir kuruluş tarafından günümüzde gelişimini sürdürmektedir. DEVICENET ile limit switch, fotoelektrik sensör, barkod okuyucu ve motor starterleri gibi düşük seviyeli aygıtlara bağlanılabilir ve PC veya PLC gibi daha üst seviyeli aygıtlarla haberleşme sağlanabilir
• FOUNDATION FIELD BUS: Özellikle dağıtılmış proses kontrol uygulamaları için dizayn edilen Fieldbus Foundation (organizasyon) olarak dünyadaki otomasyon sistemlerinde yaklaşık %80 'lik bir pazara sahip olan 140 şirketin biraraya gelmesi ile oluşmuştur. Teknolojisi fiziksel katman, haberleşme çatısı ve kullanıcı katmanından meydan gelmektedir.

Oracle WorkSpace Manager  farklı WorkSpace ler oluşturup tabloların farklı sürümlerini bu çalışma alanlarında kaydedebileceğimiz bir yapıdır. Aşağıdaki gereksinimleri karşılar.

• Kayıt güncelleme ve eklemelerini Production DB’ye uygulamadan önce gruplar halinde yönetmek.
• Veri tabanı tasarımını yönetebilmek için.
• Birden farklı senaryoda verilerin farklı sürümlerine göre analizler yapabilmek için.
• Veri değişikliklerini saklamak için.

Bu işlemlerin tümü DBMS_WS paketindeki procedure’ler yardımı ile yapılır. Bu procedurelerden en önemlileri

o   DBMS_WM.CreateWorkSpace

o   DBMS_WM.GotoWorkSpace

o   DBMS_WM.EnableVersioning

o   DBMS_WM.DisableVersioning

o   DBMS_WM.BeginDDL

o   DBMS_WM.CommitDDL

o   DVMS_WM.SetDiffVersions

Veri tabanında bulunan tablolardan birini EnableVersioning procedure ile version-enabled hale getirirsiniz. Bu işlemi yaptığınızda WorkSpace manager bu tablo ile ilişkili bazı VIEW lar oluşturur, tablo yapısında bazı değişiklikler uygular ve sadece DBA kullanıcıların görebileceği bazı nesneler oluşturur.

Yaptığı en önemli değişiklik  tablonun adını<TABLE_NAME>_LT şeklinde değiştirmesi ve eski tablo ile aynı isimde bir VIEW oluşturmasıdır. Ama kullanıcılar tüm SQL sorgularında hala aynı ismi kullanmaya devam etmelidir.

Bir tablo version-enabled hale getirildiğinde tüm satırları  çoklu versiyon desteğini sağlar. GotoWorkSpace procedure ile değişik workspaceler arasında seçim yapıldığında  seçtiğiniz workspace de version-enable hale getirilmiş olan tablonun verileri ilgili versiyondaki hali ile görebilirsiniz.

Version-enabled bir tablo için <table_name>_DIFF isimli view workspace manager tarafında otomatik olarak oluşturulur. Bu view SetDiffVersions procedure ile alınan iki workspace için tablodaki verilerin farklıklarını gösterir.

<table_name>_HIST view ise tablodaki verilerin geçmişini gösterir.

Dikkat Edilmesi Gereken Hususlar

• Version-enabled tabloda primary-key  alanın değerini güncelleyemezsiniz. Güncelemeyi denerseniz

  ORA-20003: cannot modify primary key values for version-enabled tables

  hatası ile işlem iptal edilir.

• Workspace isimleri büyük-küçük harf ayrımına duyarlıdır.(case sensitive)
• WorkSpace adı maksimum 30 karakter olabilir.
• WorkSpace ler aralırında hiyerarşi oluşturabilir. Bu hiyerarşi maksimum 30 seviyede olabilir.
• Version-enabled tabloda insert,update,merge komutları RETURUNING yapısını desteklemez.
• Version-enabled tabloda bir DDL(Data Definition Language) işlemi gerçekleştirmeden önce mutlaka DBMS_WM paketindeki beforeDDL ve CommitDDL procedureleri çalıştırılmalıdır.

  Aksi halde ORA-00942: Table or view does not exists

  hatası alırsınız.

• Alter table ifadesinde tablo isminin sonuna _lts eklendiğine dikkat ediniz.

 
   EXECUTE DBMS_WM.BeginDDL('TEST_TBL');
   ALTER TABLE TEST_TBL_lts ADD (aciklama VARCHAR2(100));
   EXECUTE DBMS_WM.CommitDDL('TEST_TBL');
 

• Version-enabled bir tabloda partitioned,reverse veya join index oluşturamaz veya drop edemezsiniz.
• Eğer yabancı anahtarla bağlanmış iki tablodan baba tablo version-enabled yapılmışsa çocuk tabloda yapılmalıdır.
• Version-enabled bir tabloda sadece per-row tirgger yapısı desteklenir.
• Version-enabled bir tabloyu drop etmeden önce mutlaka DisableVersioning procedure kullanmalısınız aksi halde

  ORA-20061: versioned objects have to be version disabled before being dropped

  hatası ile işlem iptal edilir.

   
  exec DBMS_WM.DisableVersioning('TEST_TBL’)
  

  yukardaki sql komutu ile versionlama devre dışı bırakılabilir.

Şafak sorgulaması yapmak için yaptığım form.

Bundan sonra buradan bakabilirsiniz.

Şafağını öğrenmek için burayı tıkla.

Şafağa göre çıkan yorumları beğeneceğinizi umuyorum.