Category Archives: Veri Tabanı Mimarileri

MySQL Peformans Optimizasyonu

Bu yazımla yıllardır edindiğim tecrübeler ve araştırmalar sonucu elde ettiğim bilgiler dahilinde bir MySQL sunucusunda dikkat edilmesi gereken performans noktalarını anlatacağım. Ayrıca teknik komut ve kodlardan çok teorik bir anlatım olacak. Mümkün olduğu kadar çok konudan bahsetmek istesem de epey uzun ve dallı bir konu aslında. Bu yüzden bazı yerlerde köşeli parantezler içerisinde dip notlar ekledim ve bu notları konunun dağılmaması için yazının sonunda açıklamaya çalıştım. Umarım faydalı bir yazı olmuştur. Zaman buldukça bu yazıda bahsettiğim ayarlarla ilgili olarak örnek içeren yazılar yazmaya çalışacağım.

Bir sistem için performans ayarlaması yaparken birçok etken göz önünde bulundurulmalı. Veri tabanı sunucuları için ise aşağıdaki etkenler önemli rol oynar:

  1. Table Engine
  2. Read/Write oranı
  3. Tutulan verilerin ortalama büyüklükleri ve türleri (text,int vs), toplam veri tabanı boyutu.
  4. Bağlantı sayıları
  5. Sorguların yapıları ve içerikleri.

Bu maddelerin bazıları sadece veri tabanı için önemli bazıları ise veri tabanı sunucusunu kuracağınız işletim sistemi ve donanım özellikleri içinde önemli etkenler. Örneğin Read/Write oranı size nasıl bir disk yapısı kuracağınız, kullandığınız disklerin yapılarını hatta işletim sisteminde kullanacağınız dosya sistemini bile değiştirebilir.

Verilerin boyutu özellikle dosya sistemi üzerinde önemli bir rol oynar. Bu etken sadece veri tabanı içerisinde tutulacak verilerle sınırlı değildir. Örneğin bir statik içerik sunucusu içinde önemli bir etkendir.

Bunların yanı sıra kullandığınız/tercih ettiğiniz teknoloji, sistem ve yazılımların çeşitli darboğazları olabilir. Örneğin, dosya sistemi olarak ReiserFS tercih etmeniz, çabuk yıpranan ve kolayca bozulabilen bir dosya sistemi sağlar. Fakat küçük dosya boyutları için ideal bir çözüm olabilir.

Bu tarz durumlar nedeniyle özellikle veri tabanı gibi verilerin kararlı bir şekilde saklanması gereken sistemleri tasarlarken iyi araştırmalar ve testler uygulamak gerekiyor. Günümüzde bu testler sıklıkla yapıldığı için sizin bu testlere göre sistem kurmanız yanlış değildir. Tabi yaptığınız ayarlamaları sadece testlere göre değil bilerek yaptığınızı ve verilerinizi iyi tanıdığınızı düşünerek ele alıyorum.

Bu genel açıklamalardan sonra adım adım bir performans noktalarını inceleyelim. Bu noktadan sonra anlatacağım tüm adımlar Linux ve MySQL üzerine olacaktır.

Dosya sistemi:

Dosya sistemi oldukça tartışmalı bir konu. Konu veritabanı olduğunda tercih edilebilecek en iyi dosya sistemi ZFS olarak görünmekte. Fakat ZFS’nin sadece Solaris üzerinde tam manasıyla desteği olduğunu düşünürsek bu tercih Linux sunucular için gerçekçi değil[1]. Linux üzerinde ise EXT3/EXT4 ve XFS ön plana çıkan dosya sistemleri. XFS ile EXT4 arasında performans konusunda çok çok büyük farklar bulunmamakla birlikte XFS, EXT4 ‘e göre biraz daha hızlı bir dosya sistemi. Fakat en büyük artısı XFS’in EXTx sistemlerde var olan inode yapısını kullanmıyor olması. Bu sayede EXTx sistemlerin zaman zaman yaşadığı Inode tükenme sorununu[2] yaşamıyor. Bunun yanında her iki sistemde journaling desteği ile geliyor.

Eğer dosyalara erişim tarihleri sizi ilgilendirmiyorsa mutlaka diskler “noatime” parametresi ile mount edilmeli. Böylece sistemin dosya erişim tarihlerini tutması engellenecek böylece gereksiz bir Input/Output yükünden[3] kurtulacaksınız.

RAM Meselesi:

RAM, veri tabanları için can alıcı bir donanımdır. Bir çok işlem ram üzerinde gerçekleştirerek oldukça hızlı işlemler yapılması sağlanır. Özellikle InnoDB index ve keyleri buffer olarak ram üzerinde tutar. InnoDB kullandığınız veri tabanlarınız varsa formül kısaca: “Ram miktarı = toplam innodb tabloların boyutu” olacaktır. Örneğin 20 Gb boyutunda 10 tabloluk bir veri tabanınız var. Bu tabloların 3 tanesi InnoDB ve toplam 4 Gb veriye sahip. Bu varsayımda sadece InnoDB için ayırmanız gereken ram miktarı => 4Gb olmalı[4].

InnoDB pool buffer size ayarının basit formülü “RAM miktarı – Sisteme ayrılan ram” veya RAM miktarının maksimum %80’i kadardır.

İşlemci Seçimi:

Mümkün olduğunca 64Bit destekli işlemciler tercih edilmeli.  boyutuna ve gelen yüke göre 4 çekirdek olması MySQL için ideal çözümdür. MySQL ancak ciddi trafik altında ve/veya yanlış ram ayarlaması sonucunda gereksiz ve aşırı bir işlemci tüketimi yapar. Yine de ekstra işlemci ihtiyacınız varsa 8 veya 16 çekirdekli işlemciler yeterli olacaktır. Bu noktadan sonra yapacağınız şey replication, sharding gibi sunucu sayılarını arttırmaya yönelik olmalıdır[5].

Disk Seçimi:

Mümkünse SSD, değilse en az 15K RPM SAS diskler kullanılmalı. Raid yapısı olarak RAID10 veya RAID5 ideal yapılardır. Fakat RAID5 RAID01 ‘e göre yazma işleminde daha yavaş kalabilir.

Linux Kernel Optimizasyonu:

MySQL sunucusu koşturduğunuz bir linux sistem üzerinde yapmanız gereken ilk ayar kesinlikle “Open File Limit” ayarıdır. File Limit kısaca aynı anda kaç adet dosyanın açık olabileceğini belirler. Linux sistemlerde her işlem bir dosya açarak yapılır. Bu yüzden bu limitin arttırılması gerekmektedir. Varsayılan olarak 1024 adet dosya aynı anda açılabilir.

Bunun yanı sıra aşağıda ki ayaları da ihtiyacınız doğrultusunda yapmanız gerekir:

  • Bağlantılar için kullanılacak buffer ayarları
  • SYN Floodlar için maksimum kuyruk sayısı
  • TCP Fin durumları için timeout süresi. düşük tutmak daha hızlı TCP işlemleri yapacağı için CPU kullanımı düşecektir
  • Keepalive time
  • Zaman damgasının kapatılması. Böylece yoğun trafikte gereksiz IP Stack işlemlerinin önüne geçilmiş olunur.
  • Gelen bağlantı sayısı
  • Optmem Arttırımı
  • Read/Write memory ayarlaması
  • Dosya cache miktarı

Bu adımlara dikkat ettiğiniz sürece başarılı ve sorunsuz bir veri tabanı sunucusuna sahip olmuş olacaksınız.

Notlar:

[1] http://zfsonlinux.org/ adresinde görebileceğiniz gibi ZFS’in linux sistemlere port edilmesi mümkündür. Fakat kararlılık ve performans açısından tercih edilmemektedir.

[2] EXT sistemlerde her dosya bir Inode ile temsil edilir. Yoğun write işlemleri olan dosya sistemlerinde zaman zaman silinden dosyalar Inode tablolarından silinemeyebilirler. Bu durumda Inode tablosu dolacağı için hali hazırda disk dolmamış olsa bile diske yazma işlemi yapılamaz. Bu durumda fsck ile disk check yapılması gerekmektedir. XFS sisteminde Inode yapısı olmadığı için böyle bir risk yoktur.

[3] Noatime özelliği ile linux kernel bir dosyaya yapılan her erişimi dosya headerlarına yazar. Bu da yoğun disk işlemlerinde gereksiz bir IO yaratır. Tabi access bilgisine ihtiyaç duyuyorsanız bu maliyete katlanmanız gerekecektir.

[4] Teoride ve düşük trafikli sistemlerde InnoDB Buffer Pool Size toplam InnoDB verisinden daha küçük olabilir. Fakat buffer pool üzerinde tutulmayan veriler çağrıldığında ciddi performans kayıpları olur. Çünkü MySQL Buffer dahilinde olmayan veriler için disk erişimi yapar bu da veri tabanı sistemlerinde kaçınılması gereken bir durumdur. Eğer buffer için ayırdığınız ram dolduysa MySQL performans daha da düşecektir.

[5] Sharding ve Replication tamamı ile ayrı birer yazı konusu olacak nitelikte konulardır. Bu yüzden çok detaylı olarak bu noktada anlatmak istemedim.

Büyüyen sistemlerde veri tabanı mimarisi

Zaman ilerledikçe ciddi boyutlara ulaşan dijital veriler oluşmaya başladı ve bu boyutlar giderek artıyor. Bununla paralel olarak veri mimarileri ve veri tabanı teknolojileri her geçen gün gelişiyor. Peki üzerinde çalıştığımız bir projenin veri tabanı katmanını nasıl şekillendireceksiniz? Bu özellikle startup projelerin düşünmesi gereken en önemli performans noktalarından biri. Özellikle web projelerinde en büyük maliyet veritabanı kısmında yaşanıyor. Daha doğrusu IO işlemlerinin en çok olduğu noktalar maliyeti arttıran noktaların başında geliyor.

Veri boyutları büyüdükçe veri tabanı sistemleri üreten geliştirici firmalarda kendi sistemlerini bu büyüme hızına entegre ediyorlar. Yeni teknolojiler ve yaklaşımlar ile her yeni sürümlerde farklı özellikler kullanıcılara sunuluyor. Bununla birlikte geliştirilen özellikler spesifik işler için ön plana çıkmaya başladı. Bunun en büyük örneği SQL Server 2012 sürümüyle gelen “Column Store Index” özelliği. Özellikle OLAP operasyonları için geliştirilmiş yeni bir index yapısı. Row-Store’a göre farkı, indexleri kolon bazlı tutuyor olması. Böylece indexlerde gereksiz bilgi depolanmasının önüne geçilmiş oluyor ve sorgularınızın sonuçları daha hızlı oluşturuluyor.

Fakat dediğim gibi “spesifik” bir geliştirme “Column Store Index“. Özellikle OLTP işlemlerinde önerilmiyor çünkü her yazma işleminden (delete,insert, update) önce index’i kapatmanız(disable) ve işlem tamamlandıktan sonra yeniden oluşturmanız(rebuild) gerekiyor. Bu da “Column Store Index” özelliğini OLTP işlemlerinden çok OLAP işlemleri için ideal bir sistem haline getiriyor.

Sadece bununla da bitmiyor. Colum Store Index Binary, varbinary, ntext, text, image, varchar(max), nvarchar(max), uniqueidentifier, timestamp ya da rowversion, sql_variant, decimal, datetimeoffset, CLR tipleri ve XML tipleri için kullanılamıyor. Bir de primary key olarak tanımlanan int alanların uzunluğu 18 den büyük olamıyor.

Her zaman veri tabanı konusunda verileri ve işlemleri bölmekten ve sistemleri bu ayrışma sonucu optimize edilmesi gerektiğini düşünürüm. İşte Colum Store Index örneğinde olduğu gibi artık firmalar ürettikleri veri tabanı çözümlerine spesifik işler için özellikler ekleyerek bir nevi verilerinize özel çözümler sunuyorlar.

“Bölme” terimini çok fazla kaleme ayırabilirsiniz. Özellikle MySQL sistemi üzerinde kullanılan sharding yöntemleri, gibi bir çok farklı yaklaşım olabilir. Ya da en çok kullanılan “replication” süreci en basit ve etkin bölme yöntemi. Yazma ve okuma gibi farklı işleri bölerek ciddi performans artışları sağlanabiliyor.

Süreçleri ve verileri ayırmak için sadece kullandığınız sistemlerin özelliklerini değil farklı sistemleri de bir arada kullanabilirsiniz. Memcache gibi cache sistemleri, sphinx, eleasticsearch gibi arama motorları, redis, mongodb gibi key->value tabanlı nosql çözümleri ile işlemlerinizi hızlandırabilir ve veri yapılarınıza uygun olarak süreçlerinizi ayrıştırabilirsiniz.

İşler böyle olunca hangi yapıyı tercih etmeniz gerektiği, hangi mimari üzerinde hangi özellikleri aktif olarak kullanmanız gerektiği gibi ciddi bir tasarım süreci karşınıza çıkıyor. Bu süreci kısaltmanın en önemli yolu verilerinizi ve süreçlerinizi iyi tanımaktan geçiyor. Sahip olduğunuz ve üzerinde işlem yaptığınız verileri ne kadar iyi tanır, ne kadar iyi analiz ederseniz veri tabanı yapınızı o kadar iyi dizayn edebilirsiniz. Kullanacağınız teknolojileri ve sistem kaynaklarını ona göre seçebilir ve ayarlayabilirsiniz.

Eğer yeni bir projeye başlıyorsanız yapmanız gereken ilk çalışma ne tarz veriler ile çalışacağınız. Verilerinizi belli kategorilere ayrıştırabilirseniz, daha işin başındayken mümkün olan en ideal sistemi kurabilirsiniz. Tabi iş henüz yeniyken ciddi sunucu maliyetlerinin altına girmemek gerekiyor. Zaten database tarafında ki performans sıkıntısı trafik ve veri boyutları arttığı zaman ortaya çıkacağı için yaptığınız değerlendirmelerin geleceğe yönelik olduğunu unutmamanız gerekiyor. Genelde yapılan ilk tasarımlar hep detaylı ve büyük ölçekli olurlar. Bu yüzden tasarımınızı önünüze aldığınız zaman yapmanız gereken ilk şey yazdığınız kodların bu tasarıma uyum sağlayabilecek olmasıdır. Bu ayağı yaptığınızda tasarımı adım adım inşa etme olanağınız olacaktır.

Sql Server Profiler Kullanımı

Microsoft ürünlerinde en çok sevdiğim özellik bir şeyi yapmak için neredeyse tüm araçları sunuyor olması. Baz araçların kullanımları karmaşık olsa da bir ürün içerisinden o ürünle ilgili bir çok kullanışlı araç çıkıyor. Microsoft ailesi ürünlerini iyi tanıyorsanız bir çok çözümü kendi içerisinde bulabildiğinizi biliyorsunuz demektir.

Sql Server Profiler da Sql Server ile birlikte gelen profiling aracı. Express sürümleri ne yazık ki desteklemiyor. Temel olarak yaptığı iş sunucuya bağlanıp aktif olarak gelen sorguları trace ediyor ve size rapor olarak sunuyor. Aktif işlemlerin olduğu bir sunucuyu trace ettiği için veritabanı katmanında olan sorunları hızlıca tespit edebilirsiniz bu araç ile.

Rapor içerisinde sunduğu çok çeşitli bilgiler sunabiliyor Profiler. Tam listeye msdn üzerinden ulaşabilirsiniz.

Benim özellikle ilgilendiğim alanlar ise şu şekilde:

- Cpu: Milisaniye bazında Cpu time veriyor

- Duration: Milisaniye bazında sorgu çalışma süresi

- EventClass: Yakalanan durum ile ilgili tip bilgisi (Transaction commit başladı, bitti vs)

- Index ID: Olay sırasında kullanılan index’e ait id

- Reads: Mantıksal disk okuma sayısı

- TextData: Trace sırasında yakalanan olaya ait data (Sorgunun kendisi vb)

- Transaction ID: Sistem tarafından atanan transaction id. Özellikle begin, end arası durumları takip edebilmek için gerekli

- Writes: Sorgu sırasında diske yapılan yazma işlemlerinin sayısı.

Sql Server Profiler Kullanımı ise oldukça basit. Uygulamayı açtıktan sonra sıraslıyla File –> New Trace menüsünü tıkladıktan sonra karşımıza çıkan bağlantı kutusundan ilgili sunucu bilgilerini girerek sunucuya bağlantı sağlıyoruz.

Daha sonra karşımıza Trace Properities ekranı geliyor.  Bu ekranda çeşitli bilgileri girebiliyoruz. Ayrıca trace ederken kullanacağımız şablonları da bu ekranda “Use the template” seçeneği ile seçiyoruz.

Dosya kaydetme vb işlemleri General tabından yapıyoruz. Esas ilgilenmemiz gereken kısımsa Events Selection tabı. Bu tab aracılığı ile hangi olayları trace edeceğimizi seçiyoruz. Oldukça geniş bir olay listesi var. Eğer tek tek seçmek istemiyorsak General tabından use the template seçeneğini kullanarak hazır seçimlerden faydalanabiliriz.

Ayrıca her bir event karşılığında hangi kolonların gösterileceğini de seçebiliyoruz. Seçimlerimizi yaptıktan sonra Column Filters butonu ile kolonlara filtre verebiliriz. Örneğin belirli kullanıcılara ait işlemleri ve ya belirli bir süreden uzun olan sorguları listeletebiliriz.

Tüm bu ayarları yaptıktan sonra Run butonu ile trace işlemini başlatabiliriz.  Artık önünüzde istediğiniz bilgileri içeren tüm sorgu ve işlemler listelenmeye başladı.

MS Sql Performans İpuçları

Konu veritabanları olunca optimizasyon önemli ve uzun soluklu bir yol olabiliyor. Çünkü veritabanlarının çalışmasını etkileyen çok fazla parametre var.

Bu parametrelere istinaden biraz uzun maddelerden oluşan performans ipuçları paylaşacağım. Tabi bu ipuçlarının bir kısmı diğer veritabanları ve genel sunucu servisleri için geçerli maddeler olacaktır.

İş yükünü iyi tanımak ve performans verilerini sürekli gözlemlemek gerekiyor. Bu durum tüm sunucu işleri için geçerli bir durum zaten. Genel olarak SQL Server için, belleğiniz ne kadar büyükse o kadar fayda sağlarsınız. Fakat iş yükünüzün durumuna göre diğer performans noktaları da önemli olabilir. Bu yüzden sürekli cpu, memory, disk gibi noktaları takip edip, ilgili iyileştirmeleri yapmak çok önemlidir.

Sql Server çalışan bir sunucu üzerinde başka uygulama ve servisler çalıştırmayın. Aslında bu kural bir kaç istisna dışında (webserver-memcache ortak çalışması gibi) tüm sunucu servisleri için geçerli bir parametre. Nedeni ise farklı servislerin farklı konfigürasyon ve donanım ihtiyacı ve donanımsal kaynakları farklı mantıklarda tüketiyor olması.

Birden fazla disk kullanıyorsanız, disk kontroller donanımlarıda birden fazla olmalı. Çünkü depolama birim kontrol kartları throughput sınırlarına sahiptir. Bu da yoğun trafikte tek kart ile sıkıntı yaşamanıza neden olabilir.

Uygun Raid yapılarını kullanın. Bir raid yapısı seçerken dikkat ettiğiniz noktalar genellikle; fiyat ve performanstır. Sql server’ı kullanacağınız işlem türüne göre raid seçmek çok önemli. Örnek olarak RAID 5, RAID 0+1 den daha ucuzdur ve RAID 5 okuma(read operations) işlemlerinde yazma(write operations) işlemlerinden daha iyidir. RAID 0+1 daha pahalı olmasına rağmen yazma işlemlerinde daha başarılıdır. Yazılımsal olarak yapılan raidler daha ucuzdur fakat iş yükünü işlemciler çekeceği için yoğun işlemlerde yoğun bir cpu kullanımı olacaktır. Raid konusu sadece mssql ile ilgili değil tüm sunucu işlemleri için benzerdir. Yapılan işe uygun raid yapısı seçmek son derece önemlidir

Eğer yoğun işlem gören tablo ve indexleriniz varsa bunları ayrı bir fiziksel disk üzerine taşıyarak disk işlemlerini hızlandırabilirsiniz. Burda ki temel amaç daha az yoğun olan işlemlerin yavaşlamasını ve süreçlerin bir birini etkilemesini engellemek.

OLAP (Online Analytical Processing) ve OLTP (Online Transaction Processing)  işlemlerinizi ayırın. OLAP ve raporlama işlemleri düşük öncelikli olmasına rağmen uzun süren sorgulara sahiptir. Bunun tersine OLTP ise yüksek öncelikli ve kısa süren işlemlerden oluşur. Bu iki tarz işlemin aynı sunucu üzerinde çalışıyor olması ile OLAP işlemlerinin insert ve update gibi transaction işlemlerini bekletebilir.

Tempdb veritabanını ayrı bir diske koyabilirsiniz. Tempdb Group By, order by gibi işlemler yapılırken kullanılan geçici depolama alanıdır. Bu işlemlerin diğer işlemleri aksatmaması için ayrı bir disk üzerinde tutulması performans kayıplarını engelleyebilir.

Veri ve log işlemleri için ayrı fiziksel disk kullanın. Bu şekilde sadece yazmak üzere çalışan log işlemleri ile random (read,write karışık) bir kullanım yapan veri işlemlerini ayırmış olursunuz.

Table Partitioning kullanabilirsiniz. Table Partitioning ile verileri aynı tabloda tutarsınız fakat sık kullanılan verilerinizi daha hızlı disklerde tutma olanağı sağlarsınız.

Index kullanın. Index kullanımı sorgularınıza ciddi hız kazandıracak ve daha az sistem kaynağı tüketmenizi sağlayacaktır. Özellikle, where, order by ve group by gibi durumlarda indexler büyük kolaylık sağlar.

Non-Clustered indexler yerine clustered indexleri kullanmayı tercih edin. Bir tablo sadece bir clustered index’e sahip olabileceği için index’e dahil olacak kolonları çok iyi seçmeniz gerekmektedir.

Eğer az sayıda sonuç döndüren sorgularınız varsa bunlar için non-clustered index kullanabilirsiniz. Fakat git gide çoğalacakları için ileride yoğun performans sıkıntıları çekebilirsiniz.

Bir sorgu için index oluştururken o sorguda geçen tüm kolonları tek bir index içerisinde toplayabilirsiniz.

Ek olarak indexleri belli periyotlarda tekrar oluşturmak önemlidir. Insert, Delete, Update gibi işlemler sonrası indexler parçalanır (fragmanted) bu süreç sonucu zamanlar performans düşer. Clustered index olan tablolarlar da indexleri yeniden oluşturmak tablo yu da birleştirmek anlamına gelmektedir (defragmenting) bu da size ek olarak performansa katacak bir fayda sağlar.

Kullanmadığınız indexleri silmek gereksiz yükleri ve performans kayıplarını en aza indirecektir.

Index konusunda ki bir kaç nokta tüm databaseler için geçerli olan bir durumdur.

Sadece ihtiyacınız olan verileri çekin. Select sorgularında “*” kullanmaktan kaçınmalısınız. Böylece gereksiz kolon çekme işlemlerini yapmamış olursunuz.

Mümkün olduğu sürece transaction işlemlerini “WITH NOLOCK” parametresi ile yapın. Böylece aynı satırlara erişmek isteyen sorguları engellememiş olursunuz.

Sorgularda parametre kullanarak sorguların performansını arttırabilirsiniz. SQL Server Query Optimizer yeni kullanılan sorguları hafızasında tutar. Böylece daha hızlı sorgu çalıştırılması sağlanır.

Kolonlar için en küçük veri tipini seçmelisiniz. Mümkün olduğu kadar kolonlar için veri tipi seçerken işinizi görecek en küçük tipi seçmeye gayret edin.

Text yerine Varchar kullanmaya özen gösterin. Varchar 8000 kelimeden daha küçük verileri saklayabilir. Text ise fazladan yer kaplayacaktır bu da performans kaybına sebebiyet verebilir

Trigger kullanıyorsanız uzun süren trigger işlemlerinden kaçınmanız gerekiyor. Triggerlar genellikle bir sorgu sonucu çalışan süreçlerdir ve diğer sorguları bloklarlar.

Not Like gibi pahalı sorgulardan uzak durun. Like gibi sorgular genellikle tüm tabloyu tarayarak sonuçları döndürür ve içerisinde regex gibi ifadeler kullanıldığı için sorgular oldukça uzun sürebilir.

Sorgularınız için çalıştırma planlarını gözden geçirin. SQL Query Analyzer üzerinde Display Execution Plan seçeneğini işaretleyerek sorgularınızı tekrar çalıştırın ve oluşan planı iyice inceleyin. Çalışan bir sorgu planını anlamak sorgu optimizasyonunun ilk noktasıdır. Eğer çalışma planını iyi anlarsanız gerekli index yapılandırmalarını daha kolay yapabilirsiniz.

İstatistikleri kontrol edin. SQL Server Query Optimizer kullanılan indexler için istatistik tutar. Eğer bu istatistikler güncel değilse o indexler kullanılmıyor demektir ve silinmesi gerekmektedir.

Ve son olarak periyodik bakımlarınızı aksatmadan yapın. Sistemi sürekli gözleyin ve yeni gelen sorguları kontrol edin.

Mysql replication duplicate entry hatası ve çözümü…

Mysql replication sisteminizde bir şekilde master sunucuda sorun oluduğunda slave sunucular veri aktarımını kaybedebilir. Böyle bir durumda sistemi tekrar ayağa kaldırdığınız zaman slave sunucular üzerinde “Duplicate Entry” hatası ile karşılaşabilirsiniz.

Bu hata slave sunucularda var olan bilgilerin tekrar yazılmak istemesi üzerine oluşur. İki yöntem ile bu sorunu aşabilirsiniz. Birincisi mysql’in belirttiğiniz hataları yok sayanmasını sağlayan slave-skip-errors komutunu kullanabilirsiniz.

Fakat sorunları es geçmektense sorunları düzelten bir yöntem daha var. Percona tarafından geliştirilen Maatkit duplicate entry sorunlarını çözüyor.  Maatkit kurulumu oldukça basit bir araç.

Maatkit’i sorun olan slave sunucularına kurduktan sonra şu komutu çalıştırıp arkanıza yaslanmanız yeterli:

Verbose parametresi ile ekrana duplicate olan kayıtlar listelenecek. İşlem tamamlandıktan sonra replication sisteminizi eskisi gibi kullanmaya devam edebilirsiniz.

Mysql “Manager of pid-file quit without updating file” hatası

Eğer Mysql’i başlatmaya çalıştığınızda “Manager of pid-file quit without updating file” hatası alıyorsanız, sisteminizde çalışan mysql süreçleri olabilir.

komutu ile sistemde çalışan bir mysql süreci olup olmadığını kontrol edebilir, ve eğer versa süreç numarasını kullanarak şu komutla süreci öldürebilirsiniz:

Tabi top/htop gibi uygulamaları kullanarak süreçlere bakabilirsin.

SQL Pie Chart

Boş vakitlerimde MySQL ile ilgili araştırma, belge okuma vs işleriyle uğraşıyorum son günlerde. Bugün MySQL resmi sitesinde başlayan yolculuğum code.openark.org sitesinde son buldu. Oldukça ilginç kod paylaşımları yapılmış olan bir sayfa. Anladığım kadarı ile genel olarak SQL üzerinde paylaşımlar var.

İlgimi çeken yazı ise SQL ile yapılmış olan ve yazımın başlığını oluşturan pie chart. Sanırım bir süre boyunca boş vakitlerimde bu kodu anlamaya çalışarak geçireceğim. Buyrun ilgili link:

http://code.openark.org/blog/mysql/sql-pie-chart

MySQL ve REGEX ifadeler…

Üzerinde çalıştığımız proje kapsamında bir alan içerisinde virgülle ayrılmış sayısal ifadeler tutuyoruz. Bu alan ilgili satırın kullanıldığı farklı içeriklerin id numaralarını tutmakta. Tabi yeri geldiğinde bunları tekrar parse etmek gerekiyor.

Özellikle bu id numaralarına göre çekeceğimiz verileri belirlemek için LIKE komutu pek işe yaramıyor çünkü LIKE hem istediğimiz sayıyı çekiyor hemde bu sayıyı içeren başka sayıları da çekebiliyor. Örneğin aradığımız sayı “1″ ise LIKE komutu ile içerisinde “1″ geçen tüm sayılar geliyor. Bu da bizim istediğimiz bir durum değil açıkçası.

Bu işi nasıl yaparız nasıl ederiz diye kafa yorarken bu işi PHP tarafında yapmaktansa MySQL tarafında yapmanın daha güzel olacağını düşünüp bunun yollarını araştırdım. Tabi ilk baktığım yer olan (ki genelde hep resmi belgelendirmelere bakarım) MySQL belgelendirme sayfaları oldu.

Bu noktada MySQL içerisinde regex ifadelerinin kullanılabildiğini ve bununla ilgili bir kaç örneğe (bayağı fazla örneklere) ulaştım. İşimizi görecek çok güzel bir yapı oluşturduk kendimize, buyrun komutumuz:

Daha bir çok ilginç ifade mevcut. Sanırım zaman buldukça daha detaylı olarak inceleyeceğim.

MySQL Regex Sayfası: http://dev.mysql.com/doc/refman/5.0/en/regexp.html#operator_regexp

Netbeans & MySQL

Bir kaç günden beri Netbeans ile MySQL veri tabanına bağlanmaya çalışıyor ve başarısız oluyordum. Bu sorunu pek ilgisi olmasada Pardus-kullanicilari listesine sormuştum. Ve sayın Metin Bilgin yapmam gereken bir ayar hakkında bilgi verdi ve sorunum çözüldü. Bu konuda sıkıntı yaşayan başka arkadaşlar olur diye yapılması gereken ayar değişikliğini vermek istiyorum:

/etc/mysql/my.cnf dosyasının içinde  skip-networking satırının başına # koyulması gerekiyor.
Bu işlemi yaptığınızda sorununuz çözülmüş oluyor.

Mysql verilerini PostgreSQL’e aktarma

Son zamanlarda PostgreSQL oldukça ilgimi çekmeye başladı. Özellikle Netbeans ile yaşadığım MySQL sorunlarından sonra sanırım biraz tembelliğin yarattığı zorunluluk nedeni ile birazda PostgreSQL’in gizemli dünyasının çekiciliği ile PostgreSQL üzerine çalışmaya karar verdim. Gerçi tembellik yapıp PostgreSQL’e geçtim ama esas çalışma burada başlıyor. Neyse hemen pisi depolarından PostgreSQL’e ait ihtiyaç duyacağım paketleri kurdum. Geldi sıra MySQL verilerini PostgreSQL’e aktarmaya. Google sağolsun bu konuda oldukça güzel sonuçlar çıkardı.

Sayın Kutay Demirtas’ın blogunda Mysql tablolarını ve girdilerini Postgresql e aktarmak başlığı ile yapmış olduğu girdiye ulaştım. Oldukça yararlı oldu. Gerçi blog yazısında tablolarında aktarıldığını belirtmiş Kutay bey, fakat yapmış olduğum denemede sadece verileri çıkarttığını gördüm. Kutay beyin blogunda anlattığı komutu değiştirmeden çalıştırdım fakat tablolar çıkmadı. Neyse tablo yapılarını elle hazırlamak zor değildi. Önemli olan yüzlerce girdiyi aktarabilmekti bunuda başardım.