Merhaba, Ziyaretçi. Lütfen giriş yapın veya üye olun.

Kullanıcı adınızı, parolanızı ve aktif kalma süresini giriniz

  Gelişmiş Arama
insanın içinde varsa, commodore.gen.tr açığa çıkarır bunu.. bir nevi retro olaylarının dolunayıyız.(Arda)
commodore.gen.trGenel KategoriGenel SohbetVeritabanı Sistemleri Hakkında
Sayfa: 1 [2]   Aşağı git
Yazdır
Gönderen Konu: Veritabanı Sistemleri Hakkında  (Okunma Sayısı 7825 defa)
0 Üye ve 1 Ziyaretçi konuyu incelemekte.
skonac
Üye
***
Mesaj Sayısı: 149



Üyelik Bilgileri
« Yanıtla #15 : Ekim 01, 2020, 19:54:12 ÖS »

Abi okumanın pisini temizini bilmem ama senin dediğin NoLock komutunu kullanınca sorgunun gelme süresi 2 katına çıktı  .

Bir arkadaşım bana index rebuild komutunu kullanmamı önerdi ancak onda da bir performans artışı sağladığını görmedim.

Sunucumuzun genel özellikleri:
Intel Xeon E2640 V3 2.60 GHZ 6 çekirdekli işlemci
9,5 GB Ram
Windows Server 2016 X64 bit işletim sistemi
SQL Server 2012 R2 sql sunucu kurulu


Ayrıca sunucuda çalışan 3 - 4 tane sanal makine var bildiğim, sunucuya yapılan client bağlantı sayısı günlük 200 cihazı bulabiliyor. (Bunlara Bilgisayarlar, telefonlar, tabletler ve diğer cihazlar da dahildir.)

Tam olarak anlayabilmek adına soruyorum;
9.5gb ram i olan sunucuda 3 veya 4 adet sanal makine var, bunlardan biriside SQL Server olarak hizmet veriyor ve siz içinde 12 milyon kayıt olan bir tablodaki select i mi optimize etmeye çalışıyorsunuz?
Logged
programci42
Üye
***
Mesaj Sayısı: 214


Üyelik Bilgileri
« Yanıtla #16 : Ekim 01, 2020, 22:41:22 ÖS »

Yok hayır ana fiziksel sunucuda SQL server var bu bahsettiğim 12 milyon kayıtlı tablo fiziksel sunucuda diğer sanal makineler de de başka programlar ve SQL serverlar kurulu bunun dışında sunucuda ASP.net web sunucu mongodb veritabanı iis, FTP gibi servislerde var RAM yaklaşık %80 dululuk oranı ile işlemci de yaklaşık %75 i kullanılıyor.

Sunucunun fiziksel özelliklerini artırmayı teklif ettim ancak benden daha önce de sanırım bir kaç kez yapılmış daha fazla ısrar edemiyorum alt tarafı bi rapor çekecez uzaya roket mi gönderiyoruz niye bu kadar çok yavaş ve sıkıntı çıkarıyor diyorlar haklı olarak ben de sunucu iyi sunamıyor çok çalışıyormuş diyorum  .

Yani sizin fikriniz nedir sunucunun özellikleri bence gayet iyi şahsen hayatımda böyle güçlü bir bilgisayara bile sahip olmadım yani 12 milyoncuk kayıt görünce bayılmaması lazım bana göre.

Tabi içinde çalışan sanal makineler onun performansını düşürür biliyorum her an cevap vermesi gereken ona bağlı cihazlar var vs zaten onun kullanım amacı o o sunucu her şeyi sunması lazım anında bekletmeden Google da bir şey arıyorsunuz bilemem kaç miltar kayıt bulundu 0.678 sn re diyor mesela tabi Google süper bilgisayarlar kullanıyor ama neyse yani öyle işte...
Logged
skonac
Üye
***
Mesaj Sayısı: 149



Üyelik Bilgileri
« Yanıtla #17 : Ekim 03, 2020, 10:19:04 ÖÖ »

Sunucunuzun kapasitesi bana göre sistem kaynağı canavarı olan SQL server için hiç yeterli değil. Bu tür sunucularda kaynak planlaması yapmak için bir çok faktör hesaba katılır. Ne kadar transaction olduğu, verinin büyüklüğü, ne tür raporlar çekileceği vb. bunlara bakılarak sistem kaynaklarının olması gereken değerlerine karar verilir. Diyebilirim ki sizin sunucunuz şu anki teknolojilere göre çok geride, özellikle RAM çok az, hele hele verilen roller ve üzerinde başkaca sanal makineler olması performansı oldukça olumsuz etkiliyordur. Disk hızlarını, SQL sunucu ayarlarını vs hiç sormuyorum bile. Örneğin sunucu bir storage a bağlı ise sorun aradaki bağlantı hızı bile olabilir. Veya sunucu eski ise write cache in pili bitmiş ve artık disklere yazmayı cacheleyemediği için performansı gözle görülür azalmış olabilir. Kısacası donanım tarafında bakılması gereken bir çok nokta var.
Donanım haricinde ise veritabanı üzerindeki transaction yükü raporunuzun geç gelmesine sebep oluyor olabilir. Sorgunuzun içindeki joinlerin fazlalığı, sunucuyu veri okumaya veyahut istenen verileri aramaya itecek her türlü istekler rapor süresini uzatacaktır.
Ancak yine de eldeki imkanlarla devam etmek durumunda iseniz tavsiyem yazdıgınız sorgunun planını iyice inceleyip cost oluşturan yerlere bakın, index vs eksiklerini tamamlayın. Cost u iyice dibe indirmenize rağmen sorgu halen yavaşsa örnekleminizi küçülterek deneme yapın. Yani mevcut tablolarınızın birer kopyalarını oluşturun, içlerindeki kayıt sayılarını iyice düşürün. Bu şekilde geriye doğru giderek sisteminizdeki darboğaz nerede bulabilirsiniz diye düşünüyorum.
Logged
programci42
Üye
***
Mesaj Sayısı: 214


Üyelik Bilgileri
« Yanıtla #18 : Ekim 07, 2020, 17:39:50 ÖS »

skonac teşekkür ederim tavsiyelerin için şu an mevcut imkanlarla ilerlemek durumundayız gibi görünüyor.
Bunun dışında  yine hem bu konu ile alakalı hem de bu konudan bağımsız bir sorum daha var.

Yine bu sunucu içinde çalışan sanal makine içinde kurulu bir sql server 2012 içinde bulunan stokhr isminde stok hareketlerinin tutulduğu bir tablom var.

Bunun haricinde sadece stoğa ait isim ve bilgilerin bulunduğu bir de Stoklar tablom var.

Örnek kayıtlar şöyledir.

id  stok_id  Miktar  islem
1   10       15      Giriş
2   10        5      Çıkış
3   11        7      Giriş
4   11        4      Giriş
5   11        2      Çıkış

Şeklinde tabi tabloda bu kadar sütun yok sadece örnek olarak bunları yazdım tarih, kişi, açıklama kaydeden, değiştiren gibi sütunlarda var.

Şimdi 2 tane SQL kodu göstereceğim bunlardan hangisi daha performanslı çalışır sizce
şu an tabloda en fazla 300 kayıt olduğu için ikisini de çalıştırdım ancak tabi çok fazla kayıt olmadığı için hiç bir fark oluşturmadı ikisi de 1 sn alında yanıt verdi.

Bunlardan ilk sorguyu bir view haline getirdim ve o şekilde kullanıyorum.
Bu view i aslında Sorgu 2 olarak ALTER leyebilirim programsal açıdan da bir sorun oluşturmaz aynı sütun isimleri var zaten.

SORGU 1
SELECT        dbo.Stoklar.id, dbo.Stoklar.Stok_Adi, dbo.Stoklar.Cinsi, dbo.Stoklar.Eb_Bilgi, T1.Giren, T2.Cikan, CONVERT(int, T1.Giren) - CONVERT(int, T2.Cikan) AS Mevcut
FROM            dbo.Stoklar INNER JOIN
                             (SELECT        Stok_id, SUM(Miktar) AS Giren
                               FROM            dbo.StokHR
                               WHERE        (islem = 'Giriş')
                               GROUP BY Stok_id) AS T1 ON dbo.Stoklar.id = T1.Stok_id INNER JOIN
                             (SELECT        Stok_id, SUM(Miktar) AS Cikan
                               FROM            dbo.StokHR
                               WHERE        (islem = 'Çıkış')
                               GROUP BY Stok_id) AS T2 ON dbo.Stoklar.id = T2.Stok_id AND T1.Stok_id = T2.Stok_id


SORGU 2
Select tbl.Stok_id, Stoklar.Stok_Adi, stoklar.Cinsi, CONVERT(varchar, Stoklar.Eb_Bilgi) As Ek_Bilgi, (Select SUM(Miktar) From StokHR WHERE islem = 'Giriş' And StokHR.Stok_id = tbl.Stok_id) As Giren,
(Select SUM(Miktar) From StokHR WHERE islem = 'Çıkış' And StokHR.Stok_id = tbl.Stok_id) As Cikan,
(Select SUM(Miktar) From StokHR WHERE islem = 'Giriş' And StokHR.Stok_id = tbl.Stok_id)  -
(Select SUM(Miktar) From StokHR WHERE islem = 'Çıkış' And StokHR.Stok_id = tbl.Stok_id) As Sonuc
From StokHR As tbl, Stoklar WHERE tbl.Stok_id = Stoklar.id
Group By tbl.Stok_id, Stoklar.Stok_Adi, Stoklar.Cinsi, CONVERT(varchar, Stoklar.Eb_Bilgi)     

SQL Server 2012 de ki Execution Plan ı inceledim fakat hangisi daha çok kaynak tüketiyor tam olarak anlayamadım.

Sorgu 1 de çok daha az işlem yapmış ama yüzde oranları fazla, Sorgu 2 de ise çok iş yapmış ama yüzde oranları düşük.

Ekte Sorgu1.Jpg ve Sorgu2.Jpg Execution Plan ı görebilirsiniz.


* sorgu1.JPG (29.46 KB, 1071x315 - Görüntüleme: 240 kez.)

* sorgu2.JPG (56.56 KB, 1308x416 - Görüntüleme: 285 kez.)
Logged
Sayfa: 1 [2]   Yukarı git
Yazdır
Gitmek istediğiniz yer: