SQL Server'da Bir Tablonun Veritabanını Bulmak

Merhaba Arkadaşlar,

Kullandığım bir kod bloğunu sizinle de paylaşmak istedim. SQL Server'da birkaç instance üzerinde yüzlerce veritabanınız olabilir. Bazen öyle zamanlar oluyor ki, elinizdeki tablonun hangi database üzerinde yer aldığını bilemeyebiliyorsunuz.

Aşağıdaki gibi bir kod bloğu ile bu dertten kurtulabilirsiniz. :)

sp_msforeachdb 'use [?] select db_name() db,* from sys.tables where name like ''%TableName%'''

Sarı olan kısma tablonuzun adını yazabilirsiniz. İşinize yarayabilir.

Görüşmek üzere.

Veri Ambarında (DWH) Neden SK(Surrogate Key) Üretilir?

Merhaba Arkadaşlar,

DWH işinde, özellikle modelleme yaparken, kaynak sistemdeki arkadaşlara bir mimari kurduğumuzu anlatmak sıkıntılı bir iş. Kendileri webservise iki parametre geçtiği için, dwh etkisini de bu şekilde düşünüyorlar. :)

Girizgahı savunma-vari şekilde yaptıktan sonra, konumuza gelelim: Surrogate Keys(vekil anahtar imiş Türkçesi). 

Malumunuz, OLTP sistemlerde genelde normalize tutulan verileri incelediğimizde, genelde bir primary key olduğunu görebilirsiniz. Bu kimi zaman bir sequence, kimi zaman bir timestamp, kimi zaman bir kombinasyon(işlemtarihi-000-kurum kodu-işlem tipi-seq vb) olabiliyor. Tıpkı OLTP sistemlerde olduğu gibi, Veri Ambarı dünyasında da bir surrogate key kullanımı mevcut. Surrogate Key'ler genelde herhangi bir anlam içermeyen, sequental yapıdaki numeric alanlardır. 

Peki kaynak sistemlerde bir business key varken(ki ona natural key de diyoruz), neden bir daha SK üretiyoruz?

İlk belirtmemiz gereken neden, kaynak sistemlerdeki bu business key'ler(natural key), o sistem içinde bir anlamı olabilir. Örneğin bir şahıs şirketidir. Key olarak TCKN tutuyordur. Ancak sonrasında mevzuat değişmiştir, artık VKN(vergi no) almıştır kendisine. Dolayısıyla datanın şekli şemali tipi vs değişebilir. Bu kaynak ile ilgili bir durum. Absürt örnek vereyim, TCKN yerine de 'bjk1903' gibi bir değer de tutabilirler. Bunu izlemek, değişimleri yönetmek sıkıntı. Üstüne üstlük, bu keyin geçtiği, join kurduğu tüm alanları bulup dwh'te düzeltmek zorunda kalabilirdik. Bu nedenle business key'leri genelde string bir data tipinde tutup, karşılığında SK değer üretmek mantıklıdır. 

Bunun dışında bir diğer neden de, az önce de yazdığım üzere, bus,ness key olarak, upuzun bir kombinasyon tutulabilir. Tabi bu şekilde çok fazla yer kapalayacaktır. Dolaylı olarak performans etkisi yaratacaktır. SK ile hem yerden tasarruf edecek hem de performans sorunu yaşamayacaksınız.

Belki de kritik bir sıkıntı daha da şu: kaynakta, örneğin transactionı fazla olan yapılarda, belli bir süre sonra, truncate edilip, bu natural key'ler en baştan başlatılabilir. Bu çok riskli bir durumdur. DWH data dilmeyip, history'i saklama konusunda hassastır, malumunuz. Bu şekilde büyük işlem karmaşaları ortaya çıkabilir.

Bunun gibi nedenlerden ötürü, kaynak(operasyonel) sistemlerden çekilen tablolar için, veri ambarında genelde bir SK değeri üretilir.

Sonra görüşürüz.

Kanban: Classes Of Services

Selamlar Herkese,

Kanban metodolojisinde, backloga gelen işleri yönetmek için bir ritüel daha mevcut: Classes of Services.

Bu yöntemle gelen işleri önceliklendirmek, sıraya almak ve planlamak sağlam bir temele oturuyor. Bu konsept ile işi oturttuğunuz kategoriye göre cost of delay, yani gelen işin maliyetini daha net görebilirsiniz.

Genel anlamda 4'e ayrılır:

1. Expedite

2. Fixed Date

3. Standart

4. Intangible

Elinizde bir iş var ve sprinte alamadınız örneğin. Bu iş size kaça patlar? İşte bu konsept ile bir tahminleme yapabilirsiniz.

Önce internetten bulduğum ve çok güzel özetleyen resim ile göstereyim.

Expedite: Production bug gibi düşünebilirsiniz. Sizde bir günde milyon dolar bile kaybettirebilir. Bu şekilde bir iş geldiğinde, WIP Limit falan kalmaz ortada. Bu iş ya da işler diğer tüm işlerin önüne geçer.

Fixed Date: Regülatif değişiklikler gibi düşünebilirsiniz. Diyelim ki ssl ile bir devlet kurumuna erişiyorsunuz. Kurum kararınca 2 ay içinde TLS'e geçmeniz istendi. Eğer gecikirseniz, yaptırım ve maddi zararlar ortaya çıkar. Planlamak ve atlamamak gerekir, bu sınıftaki işleri.

Standart: Klasik standart müşteri talepleridir. Sıradaki iş direkt çekilir mantığı yani.

Intangible: Aciliyeti olmayan ama yapmazsan ileride masraf çıakrtabilecek altyapı değişimleri gibi düşünebilirsiniz. Uygun bir zaman dilimine planlanabilecek işlerdir.

Sonra görüşürüz.

SQL'de Join Çeşitleri

Merhaba Arkadaşlar,

Temel bir konuya değinmek istiyorum bugün. Zira mail üstünden gelen sorularda özellikle işin outer join kısmında bir kafa karışıklığı olduğu görülüyor. Oracle üzerinden anlatacağım konuları, gidişata göre ayrı başlıklar da açabilirim.

JOIN dediğimiz kavram, birden fazla tablodan veri almamızı sağlayan ifadeler, bağlaçlardır. 

JOIN sorgusu çalıştırırken, Oracle'da Optimizer'ın bazı kontrolleri vardır. Join'i yaparken index kullanılacak mı; full table scan mı gidecek(yani tüm tabloyu tek tek gezecek mi; yoksa nokta atışı yapacak mı gibi çevirebilirim burayı), bunu belirler. Akabinde join'e giren tablo sayısı 2'den fazlaysa, join order'ı yapar. Yani önce küçük tabloları joinler, sonra buradan dönen data set'i üstünden büyük tabloya gider. Bu sayede sorgu performansında artış amaçlanır. Son olarak da yazdığımız join'e bağlı olarak arka planda hangi join method'u(hash-sort merge-nested loop) kullanılır, bu belirlenir. Yöntemlere kısaca ayrı bir başlıkta değineceğim.

Gelelim sql önyüzünde, Toad-plsql developer-sql plus gibi bir arayüzde yazdığınız join türlerine.

1. Inner Join

2. Left Join (Left Outer Join)

3. Right Join (Right Outer Join)

4. Full Join (Full Outer Join)

Öncelikle örnekte kullanmka üzere iki tablo yaratalım.

JoinTableTest1 tablosu takım bilgisi tutuyor olsun.

JoinTableTest2 tablosu da oyuncuları tutuyor olsun; TakımID de foreign key'i ve bu kolon üstünden join kuralım. Tablolar ve alanlar çok uyduruk. :) Joini anlatmak için hızlıca oluşturdum, mantıksal tasarımı sıkıntılı; join'e odaklanın lütfen. :)

INNER JOIN:

İki tablonun joininde eşleşen kayıtlar için sonuç döndüren join türüdür. 

select t1.TakimAdi,t2.OyuncuAdi from JoinTableTest1 t1, JoinTableTest2 t2

where  t1.TakimID=t2.TakimID --bu eşitlikle inner join veriyoruz.

--Yani her iki tabloda TakimID'si eşit olan oyuncuları getiriyor. 

İnternetten aldığım resimle olayı açıklıyorum. 

Örneğimizde iki tabloda takımIDsi aynı olan kayıtlar getiriliyor.

Aynı sorguyu = operatoru yerine, INNER JOIN ile de yazabilirsiniz:

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1 INNER JOIN JoinTableTest2 t2

ON t1.TakimID=t2.TakimID

Bu da aynı sonucu üretir:

LEFT JOIN:

Kitabi anlatmayacağım. :) Joinin solundaki tablonun tamamı listelenir. Olayın mantığının temeli bu. Eğer select ifadesinde, sağdaki ikinci tablodan kolonlar varsa, solda olup, sağda karşılığı olmayan kayıtlar için, selectteki o kolonlar null gelir. Örnekle açıklamak en güzeli. :)

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1 LEFT JOIN JoinTableTest2 t2

ON t1.TakimID=t2.TakimID 

Şimdi örnek üstünden açıklayalım. Soldaki tablo nedir: JoinTableTest1. Bu tabloda takımlar vardı. Demek ki eşleşse de eşleşmese de, bu tablonun tüm kayıtları gelecek. Eşleşen 11 kayıt, zaten inner join'de de görmüştük, kafadan gelmiş. Ancak son 2 kayda dikkat buyurun. Oyuncuları tutan JoinTableTest2 tablosunda Trabzonspor ve Galatasaray'lı oyuncu yoktu. Yani eşleşme yok. Bu nedenle OyuncuAdı alanları NULL bir şekilde, bu iki takım da gösterilmiş. Left Join tam olarak böyle bir dünya. :)

Bu sorguyu ben yukarıdaki gibi yazmaya üşeniyorum. (+) ile yazıyorum. Bu şekilde yazmak isteyeneler için:

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1, JoinTableTest2 t2

where t1.TakimID=t2.TakimID(+)

Eşitliğin t2 kısmına (+) konmuş. Demek ki t1'in hepsini alacağız, şeklinde aklınızda da tutabilirsiniz. :)

Oracle docs'u yerle yeksan ettik. Kendimi eski hbb kanalındaki beyin egzersizci abimiz gibi hissettim. :)

Şekilsel gösterimi de şöyle:

RIGHT JOIN:

Joinin sağındaki tablonun tamamı listelenir. Left'in aynı mantığı var burada da. Eğer select ifadesinde, soldaki birinci tablodan kolonlar varsa, sağda olup, solda karşılığı olmayan kayıtlar için, selectteki o kolonlar null gelir. Ben direkt örneğe geçeyim; en temiz öyle anlaşılır.

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1 RIGHT JOIN JoinTableTest2 t2

ON t1.TakimID=t2.TakimID

Sağdaki tablomuz nedir: JoinTableTest2. Oyuncu bilgilerini tutan tablo. Eşleşen 11 kayıt yine geliyor. İlave olarak sağdaki oyuncu tablosunda TakımID'si 21 ve 26 olan iki oyuncu bilgisi de geliyor. Yalnız bu takımID'ler, JoinTableTest1 tablosunda yok. Bu nedenle TakımAdı bilgisi boş geliyor. Ancak sağdaki tablonun tüm kayıtları listelendiğinden, Nouma ve İlhan kayıtları, eşleşmese de sonuç kümesinde geliyor.

Tıpkı Left Join'de olduğu gibi, Right Join'de de, aşağıdaki gibi yazabilirsiniz.

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1, JoinTableTest2 t2

where t1.TakimID(+)=t2.TakimID

Aynı şekilde, t1'in yanında (+) olduğundan, t2'nin hepsi listelenir gibi düşünebilirsiniz.

Şeklini de verelim right outer join'in:

FULL JOIN:

Left Join ve Right Join'in birleşimi gibi düşünülebilinir. İki tablodaki tüm kayıtlar döner. Karşılığı olmayan kayıtlar için, alanlar NULL döner.

select t1.TakimAdi,t2.OyuncuAdi 

from JoinTableTest1 t1 FULL JOIN JoinTableTest2 t2

ON t1.TakimID=t2.TakimID

Gördüğünüz üzere, hem right'taki hem de left'teki kayıtları getirdi. 

Bu join tipini de şu şekilde görselleştirebiliriz; tabi ki kaynak yine internet:

Optimizer'da görülecek olan join tiplerine daha sonra değinelim; okunurluk düşüyor.

Sonra görüşürüz.

Kabul Kriterleri: Gherkin Formatı

Merhaba Arkadaşlar,

Bildiğiniz üzere user story'lerin temelde 3 bölümü vardır. Hikayenin tanımı - kabul kriterleri - bitimin tanımlanması. Şimdi Kabul Kriterleri kısmına bir alternatif oluşturan dil/model/format üzerinde duracağız: Gherkin Format/Language.

Malumunuz olduğu üzere, Kabul kriterleri müşterinin perspektifinden yapılır. Bunu en etkili kullanabileceğiniz formatlardan birisi de Gherkin yöntemidir. Kimilerine göre 3 kimilerine göre 5e ayrılır.

• Given
• When
• Then

Temelde bu 3leme üstüne kuruludur. Her bir adımda AND ile çoklayabilirsiniz. Bir de senaryoyu sayarsak, toplamda 5 yapar. Hatta daha da geliştirip daha fazla keyword kullanan da var. Evet, anlamsız gelen arkadaşlarım için adımları açıklayalım. :)

Given: description of the state of the system. Yani başlangıç durumudur. Senaryo için başlangıç noktası. 

When: customer or system action. Yani bir aksiyon alınması

Then: result of the action. When adımında alınan aksiyonun sonucu, çıktısı.

Hemen bir örnekle açıklayalım.

Örneğin ödeme sayfasında müşterilerin sorunsuzca ödeme yapabilmesi isteniyor olsun.

Given: Ödeme sayfasına girilmesi; müşterinin ödeme syafasında beklemesi

When: Müşteri ekrana, atıyorum, Krdi Kartı bilgilerini girmesi

Then: Sistemin müşteriye one-time-password(OTP) ile onay sms'i göndermesi.

Gördüğünüz gibi başarılı bir ödeme işleminde bir adımı, gayet düzenli ve anlaşılır bir şekilde kabul kriteri haline dönüştürebildik.

Görüşmek üzere.

Spotify Agile Organization - Spotify Çevik Organizasyonu

Merhaba Arkadaşlar,

Üzerinde mutabık olunamayan ama bazı firmalarca taklit edilen bir diğer Agile organizasyonu ise : Spotify Yapılanması. 

Önce kitabi kısmından bahsedelim, sonra neden itilaf oluşuyor kısaca ona değinelim.
Bir klasik haline gelen internetten resim alıntılama faslıyla başlayalım. :)

Spotify yapılanmasında da agile'daki gibi squad'lar ve bunların birer PO'su var. Tam olarak agile ritüellerini uygulamazlar. Scrum ya da kanban master'ları yoktur. Bir agile coach'a bağlıdırlar ve onunla çalışırlar.

Tribe denilen yapı, birbiriyle ilişkili olan birçok squad'ın bir araya gelmesiyle oluşan bir yapıdır. Yukarıdaki resimden de göreceğiniz üzere, bir tribe altında birçok squad ve her squad'ın da kendi Product Owner'ı vardır. Her tribe'ın da bir tribe leader'ı olmaktadır. Bir önceki yazımda bahsettiğim hiyerarşik bir yapı yok, Product Owner'lar arasında. Chief yok yani. PO'lar kendi aralarında işbirliği yaparlar. High-level bir roadmap üzerinde çalışırlar. Tribe'ın tüm PO'ları birlikte çalışır.

Chapter denen yapı ise, tribe altında, farklı squadlardan, benzer uzmanlığı bulunan kişilerin bilgi paylaşımı ve çözümler için oluşturdukları yapılardır. 

Guild'ler ise farklı tribe'lardan da katılanılan, daha genel, workshop veya atölye tarzında, isteyenin katılabidiği daha genel bir bilgi paylaşımıdır. Chapter'da örneğin arayüz geliştiricileri toplanmıştır. Guild ise tüm geliştiriciler gibi düşünebilirsiniz.

Gelelim bu yapıya yapılan itirazlara. :) Kurumların bu yapıya geçerek, sadece squad ya da direktörlük isimlerini değiştirerek, bu modeli uyguladığını sanmaları en büyük yanlışlardan birisi. Yani bu model size isimlerinizi değişitirip yola devam edin demiyor. 

Bir diğer sıkıntı da, bu model ya da yapılanma, Spotify firmasına göre yıllar içinde tecrübe edilen, denenen bir yapı. Bir modeli alayım, aynısını kullanayım çok başarılı bir yol olmaz. Bunu baz alıp firmalar kendilerine uyarlamadığı sürece, çok da başarılı olmayabilir. Örneğin, scrum master kullanıp da bu yapıyı deneyenler var. :)

Ve bu modelin arkasında Spotify'ın kendi organizasyonel ve kurum kültürü de var. Çalışanlara düşünmeleri eğlenmeleri için verilen zamanlar; hataların pişkince yüze vurulmasından ziyade, denemenin göstergesi olduğu inancı vs vs. Tüm bunları alt alta koyduktan sonra bu model daha anlamlı olacaktır.

Sonra görüşürüz.

Chief Product Owner

Merhaba Arkadaşlar,

Chief Product Owner nedir, ne değildir'i kısaca sizinle de paylaşmak istiyorum. Önce bir adım geri gidelim. Agile mantalitesinde, biliyorsunuz, bir product owner-scrum master-development team yer alır. 

Normalde product owner'lar, kitabi terimle anlatmak gerekirse, ürünün değerini arttıran ve bunu da dev team ile çalışarak yapan kişidir. 

Buraya kadar sorun yok. Soru tam olarak şu: " Tek bir Product Owner'ın başa çıkabileceğinden daha büyük bir ürün varsa ne olacak? ( what happens when the product ise too large for a single product owner?)

Bir diğer soru da şu: Tek bir ürün üzerinde çalışan birçok takım varsa ne olacak? ( what happens when you have dozens of teams working on a single project?)

Tam da böyle durumlara karşı, agile organizasyonel yapılanmasında bir kavram karşımıza çıkıyor: Chief Product Owner. 

Chief Product Owner, daha üst seviyeden kararlar alabilen, takım product ownerlarının kendisine bağlı olduğu ve bu takım product owner'larına yön veren kişidir.

Bu yapılanmadaki anahtar kelime HİYERARŞİ'dir (hierarchical organization). Burada ast-üst olayı var yani.  İnternetten yine hazır bir resme kondum; kendim çizmedim, onu paylaşayım sizlerle.

Yani daha üst seviye olaylara bakan, stratejik kararları veren, ürünün nereye gideceğini belirleyen ve hatta bunun için karar verici paydaşlarla görüşen kişidir. Takım PO'su gibi detaylarla ilgilenmez.

Sonra görüşürüz.

Çocuğumu Hangi Okula Göndermeliyim?

Merhaba Herkese,

Her zaman bilişim ile ilgili yazı yazamayabilirim. :) Benim gibi çocuğunu okula gönderme konusunda başlangıç noktasında olan, yön almak isteyen veya neler yaşandığını duymak isteyen arkadaşlarımız vardır diye yazmak istedim. Zira ben her yazılanı tek tek okudum. :)

Öncelikle ben ilkokul aradım. Aklınıza gelebilecek her şeyi okudum; size de tavsiye ederim: "okul seçerken nelere dikkat etmeliyim", "okul seçimindeki kriterler nelerdir", "doğru okulu nasıl bulmalıyım" vs vs. :)

Her şeyi dinleseniz de mutlaka potansiyel okullarınıza gidin sevgili arkadaşlarım. Bir defa okulu görün. Yerini, muhitini görmeniz iyi olacaktır. Herkesten duyacaksınız, ilkokul seçimi aslında öğretmen seçimidir. Yüzde yüz haklıdır da. Ancak kişisel görüşüm bununla sınırlandırmamak yönünde. Birçok okul gezdim. Hepsinde müdür ve müdür yardımcılarıyla görüştüm. Evet belki haddim değil, belki yanlış bir bakış açısıdır ama konuştuğum idarecilerden dolayı elediğim okullar oldu. İletişime açık olmamaları veyahut konuşmaları benim o okulları direkt elememe yol açtı. Bunun yanında bahçesi bile olmayan okullar türemiş; örneğin bu bile bir kriter olabilir. Salgın süreci olmasa, okul aile birlikleri aslında tek adresiniz olmalı. Okul aile birliğindekiler size okul nasıldır, hangi öğretmenler sevecen, hangileri çocuklar üstünde otorite deniyor vs her şeyi anlatıyorlar. Şanssızlıktır ki, bu süreçte bulmanız kolay değil. 

Okulların yan aktiviteleri/dersleri de önemli. İsteyene satranç isteyene halk oyunları gibi birçok ilave ders olması da önemli. Bunun için küçük bir maddi destek gerekebilir. Bunun dışında güvenlik, hemşire, temizlik gibi konular da kriterlerden sayılabilir. 

Yaşadıklarımı yazmak istedim; benim durumumdaki arkadaşlarımın işine yaraması dileğiyle. :)

İyi Geceler

Linux'ta Ortak Disk Sorunu ve Yama Çözüm

Merhaba Arkadaşlar,

Windows ya da Linux fark etmeksizin, uygulama makinalarınız ortak diskleri görüyordur. NFS ya da CIFS kullanıyor olabilirsiniz. Buradaki amaç, uygulamalarınızın ortak dosyaları görebilmesidir. Örneğin, sözleşme gibi önemli bir dosyayı bir uygulama sunucusundan ekrana bağlandığınızda görüp, diğerindeyken görememeniz kabul edilemez. Veyahut bir web siteniz vardır; bir kullanıcı arayüzden girip, siteye resim yüklemiştir. Bir başka kullanıcı başka bir makinaya düştüğünde o resimi göremezse, takdir edersiniz ki çok saçma olur. Ortak diskler bunun için vardır. Bunun da çok detayı vardır. IP bazlı, kablolu vs diye ama ona girmeyeceğim, asıl konum bu diskler değil zira.

Diyelim ki ortak diskte bir sorun var. Tabi ki storage ekibiniz hızlıca müdahale edecektir. :) Ancak storage ile uygulama farklı networktedir ve network sorunu vardır vs vs. Böyle durumlarda kısmet deyip beklemek kabul edilemez takdir edersiniz ki. =) Böyle durumlarda, uygulama üstünde ortak diski, herhangi bir uygulama sunucusu ile değiştirmeniz gerekiyor. Akabinde sunucuları sync etmelisiniz. Yani hangi sunucudan döküman, nesne yüklenirse yüklensin, hızlıca sizin belirlediğiniz, ortak disk olarak hizmet verecek uygulama sunucusuna bunları göndermeniz gerekecektir. Bunu da linux'taki rsync komutu ile yaparız. 

Örnek komut satırı:

rsync -avhz /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/uploads makina2:/gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/

Uploads altında ne varsa, ikinci makina altına atmış olacaksınız. Tüm uygulama sunucularınızda bu scripti çalıştırıp, shell olarak kurarsanız, düzenli olarak atmış olursunuz. 

Yazıyı bitirmeden de çok kısa rsync komutuna değineyim, daha önce kullanmamış arkadaşlarım için. Rsync komutu bu şekilde, dosya transferi, günlük delta backuplar, incremental backuplar gibi, farkları bulup, onları kopyalayan bir komuttur. 

rsync -parametreler kaynak hedef  şeklinde bir notasyonu vardır.

Yukarıdaki örneğimde kaynak: /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/uploads 

hedef: makina2:/gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/

Burada iki farklı makina yerine, aynı makina içinde yapsaydım, hedefte makina2'yi ayrıca belirtmeye gerek kalmazdı. Bu durumda hedef: /gurkan/wsadmin/WS-Docs/gurkanalkan.blogspot.com/wp-content/ olurdu.

Kullandığım parametreleri ise şöyle:

-a dosya veya diizne ait her şeyi arşivleyerek taşır(rol-izin-mtime gibi)

-v yaptığımız işlemin detayını ekranda, konsolda görmemizi sağlar.

-h bizim okuyabileceğmiz bir çıktı oluşturur(Human readable)

-z dosya ya da dizini sıkıştırarak alır.

Sonra görüşürüz.

Web Sitenizde Otomatik Restart Shell Scripti

Merhaba Arkadaşlar,

Web sitesi işlerinde çok temel seviye dedim ama sonuçta shell işlerinde o kadar da yeni değiliz. :)))
Başıma gelen bir olay ve nasıl bir ara çözüm uyguladığımı paylaşacağım. Elimdeki web sitesi çok temel seviyede olan, caching'i zayıf denebilecek, yüksek trafikleri kaldıramayacak basit bir mini site idi. Ancak bir şekilde web siteme aşırı yük geldi. :)

Eğer sizin de web sitelerinize fazladna yük geldiyse ve/veya web sitenize restart atmak isterseniz aşağıdaki gibi ilerleyebilirsiniz.

Öncelikle apache altında, executables'larınız her nerdeyse, altında bir sh dosyası oluşturmalısınız. Örneğin apache/exec altında olsun.

1. oto_restart.sh oluşturun.

2. İçine şunları yazın:

./stop-apache-WS    (sizin apacheyi kurarken apache stop scriptiniz her neyse, onu yazarsınız)

sleep 3                      (3 saniye bekle dedik, ki tüm processler kill olsun)

./start-apache-WS    (sizin apacheyi kurarken apache stop scriptiniz her neyse, onu yazarsınız)

3. chmod +x oto_restart.sh    (yetkilendirmenizi yaparsınız)

4. while [[ 0 -ne 1 ]]; do ./oto_restart.sh;   sleep 300; done  yazıp çalıştırabilirsiniz.

Bu sayede 300 saniyede bir oto_restart.sh çalışmış olacak. Yani 5 dakikada bir restart etmiş olacaksınız. Böylece site down olmayacaktır. Tabi bu işlemi yaparken db'nin durumunu da gözlemlemeniz iyi olacaktır.

Bu mantıkla web sitenizi de auto restart atabilirsiniz; herhangi bir apache platformunuzu da otomatik olarak restart edebilirsiniz. Genel mantık bu şekilde.

Sonra görüşürüz.