Netsis TBLSERITRA ve TBLSTHAR Bağlantısı Hakkında

Netsis Programı SQL Server 2008 R2  veritabanında serili stok hareketlerinin  kayıt altına alındığı 2 tablo bulunmakta bunlar TBLSTHAR ve TBLSERITRA tabloları olup TBLSTHAR INCKEYNO TBLSERITRA ise STRA_INC Primary keyleri ile birbirine bağlı olmak zorunda yani 1 adet stok hareketinin karşılığı 1 seri demek oluyor.Stok yaşlandırma'da bulunan eksi bakiye sorununu çözmek için yedek şirkette devir ile gelen eksi bakiyeyi TBLSTHAR ve TBLSERITRA tablosundan Delete komutu ile sildiğimde yaşlandırma raporundaki eksi bakiye sorunu ortadan kalkmış oldu.Bu sefer tam tersi düşünerek sildiğim bu kayıtları yeniden eski yerlerine almak istedim.Farklı bir yedekten SERITRA tablosundaki kaydı sorunsuz eski yerine taşıdım diğer kaydı TBLSTHAR tablosuna taşımak istediğimde ise INCKEYNO identity değeri aldığı için hata verdi.Böyle durumlarda aslında identity seçeneği tablo dizaynından iptal edilebilir ama üretim veritabanlarında böyle bir durum risk oluşturacağı için yedekteki ilgili kaydı INSERT INTO komutu ile TBLSTHAR tablosuna INCKEYNO değerini yazmadan ekledim böylece sorunsuz olarak hem doğru kayıtlar eklendi hemde INCKEYNO  otomatik olarak yeni değer aldı.TBLSTHAR tablosunda bulunan yeni INCKEYNO değerini TBLSERITRA tablosunda bulunan STRA_INC alanına eşitlemek için ise TBLSERITRA tablosundaki eski STRA_INC değerini TBLSTHAR tablosundaki ilgili hareketin aldığı yeni INCKEYNO değerine UPDATE komutu ile ekleyerek her iki tablodaki INCKEYNO ve STRA_INC alanları stok hareketi ve seri kaydı olarak birbirine sorunsuz bağlanmış oldu.

SQL Server Recovery Modelleri

Şirketimizde kullandığımız ERP programının kullandığı veritabanının Recovery Mode'nu daha önce Simple Recovery Mode düzeyinde tutuyorduk. Şirketimizde yapılan IT Denetlemesi sonucu denetimi yapan ekibin  Erp programında yapılan değişikliklerin geçmişe yönelik olarak  görülebilmesi gerektiğini söylemeleri üzerine sene başından itibaren Recovery Mode'u Full Recovery Mode'a alarak yapılan insert-update-delete işlemlerini görmeye başladık. Veritabanı Full Recovery Mode düzeyinde olunca bu defa transaction logların tutulduğu ldf dosyasının otomatik büyümesinden dolayı sene ortasına gelmeden mdf dosyasının boyutunu geçtiği durumlar da olmakta.

Resim- Full Recovery Mode'da MDF ve LDF dosyalarını göstermekte(Burada ldf dosyası mdf dosyasının boyutuna henüz ulaşmamış)

Sunucu yapılandırmanız ne kadar iyi olsa da bu defa yapılan işlemler transaction log dosyasına (ldf) yazıldığı için üretim sonu kaydı yaptığımız programı kullanan arkadaşlar üretim sonu kaydının yapıldığı anda sistem de yavaşlık olduğunu söylediler. Sorun, belirli periyotlarda otomatik transaction log yedeği  alınarak çözülmüş oldu. 15 dakikalık periyotlarla alınan transaction log yedeklerinin genelde mesai saati içinde boyutu yükselmekte ve bu boyut şirketinizde yapılan veritabanı operasyonu ile orantılı olarak kısa bir zamanda artabilmektedir. Alınan transaction log yedekleri kapasitesi yüksek depolama aygıtında arşivlenirse geçmişe yönelik hareketlere erişmiş oluruz.

Resim-15 dakika ara ile alınan transaction log yedeği.Yapılan insert-update-delete işlemine göre boyutlar farklı görünmekte.

Cannot insert the value NULL into column 'ID', table 'dbo.test'; column does not allow nulls. INSERT fails.Hatası

SQL Server'da yeni oluşturduğumuz tablomuzda primary key değeri olan integer veri tipine sahip bir alanımıza veri aktarırken(INSERT INTO) aşağıdaki hatayı alıyor isek (devamlı unuttuğum ve  başıma sık gelen bir durumdur:)).Tablo dizaynına girerek dizayndan is identity değerini Yes olarak değiştirmeliyiz.Bu sayede ID değerini otomatik alıp boş geçmeyecektir.Bizde bu hatayı almayacağız.

Identıty değerini değiştirme ekranı;

LYNC 2013 Oturum Açma Sorunu

Office 365 sistemi ile gelen sesli ve görüntülü iletişim programı olan Lync 2013 programı ile şirket içinde oturum açmak istediğimizde bağlantı kuramıyorduk.Şirket içindeki sunucumuzda iç DNS sunucu kullanıyoruz ve dış dünyadada aynı isimde dış DNS hostingimiz mevcut olduğu için iç DNS sunucudaki zone'a LYNC sunucu cname kayıtlarını girmemiz gerekmekte olup bu kayıtlar girilince bağlantı sorunu çözülmektedir.Girmemiz gereken DNS CNAME kayıtları;

sipdir.online.lync.com.  sip  CNAME Kaydı

lyncdiscover webdir.online.lync.com.  CNAME Kaydı

DNS Konsol Lync Kayıtları Resmi için;

SQL Server Performans Sorunu-Transaction Deadlock

İşletmemizin farklı yerdeki şubesinde üretim sonu kaydı yaptığımız özel yazılım barkod-üretim takip programında sadece belirli stok kodlarında barkod etiketi çıkartıp üretim sonu kaydını yaptığımız esnada uzun süre bekleme olup çoğu zaman transaction deadlock tarzı hatalar almaktaydık.İlk esnada gecikmenin network ile alakalı olabileceğini düşündüğüm için temel network izleme komutu olan ping komutu ile SQL sunucunun çalıştığı sunucu'ya ping komutu gönderdim herhangi bir paket kaybı yoktu ve PC'den giden paketler 1 ms'den düşük olacak şekilde hedefe ulaşmaktaydı.Buraya kadar sıkıntı yoktu.Ardından yazılım desteği aldığımız firmadaki arkadaş ile SQL Sunucu'da SQL Profiler çalıştırıp column filter'dan karışıklılık olmaması için üretim takip programının ismini yazarak izleme yaptık ve darboğaza-beklemeye girdiği yerdeki T-SQL söz dizimini yakaladık.





Söz diziminin çalıştığı view'i yakaladıktan sonra üretim sonu kaydı yaptığımız stok kodunda fazla hareket olduğu için ve üretim takip programı tüm bu kayıtlara baktığı için geç cevap döndürüyor bu sebepten dolayı üretim sonu kayıt işlemi epeyce geç oluyordu.Sorguyu farklı stok kodları ile denediğimizde çoğunda 4 saniye'de cevap dönerken sorunlu olan stok kodundan 60 saniye civarında sorgu dönüyordu.Sonuç olarak bir çok çözüm yolu olabilir diye düşünüyorum -örn:index rebuild- arkadaş view üzerinde bizim kullanmadığımız alanları sorguda yorum haline getirip üretim  sonu kaydını yeniden deneğimizde çok kısa sürede sorgu cevabı gelmeye başladı sorun bu şekilde çözülmüş oldu.SQL sunucu darboğaz yönetimi gerçekten farklı bir konu ilk başta gecikmenin network'ten olabileceğini düşünsekte profiler'ın yardımı ile darbogazın fazla stok hareketi ve sorgu optimizasyonu ile çözülebileceğini görmüş olduk.

Office 365 Desktop Manager Yükleme hatası Çözümü

Windows 8.1 64 bit işletim sistemine Office 365 Desktop Manager yüklerken 0x800f0906 .net framework 3.5 yükleme hatası alır iseniz aşağıdaki adımları uygulayın;
 
-Windows 8.1 yükleme medyasını (DVD) DVD sürücünüze yerleştirin.
 
-Komut istemine yönetici olarak girerek aşağıdaki komutu çalıştırın;
 
Dism /online /enable-feature /featurename:NetFx3 /All /Source:X:\sources\sxs /LimitAccess 


X  ifadesi DVD sürücünüzün ismi farklı olabileceği için belirtilmiştir.


Komutu çalıştırdıktan sonra sorun çözülecektir.

ilgili resim için;

 

The file or directory is corrupted or unreadable Hatası Ve Çözümü

ISCSI disk olarak sistem'de görünen Nas disk Sunucu yeniden başlayınca offline konuma geçmiş disk management üzerinde yeniden online konuma getirince sorun düzelmişti.Ama bu sefer efatura SQL yedeği aldığımız alt klasöre erişmek istediğimizde "The file or directory is corrupted or unreadable" hatası alamakta olduğumuz için klasör içeriğini görememekteydik(ilginç olan SQL Job yedekleri hatasız almaktaydı)
Bilindik bir çözümdür fakat bu sorunu ilgili ISCSI disk üzerine gelip özellikler-araçlar bölümünden CHECK komutu ile disk tarama yapıp hataları düzeltimesini sağladıktan sonra yeniden alt klasöre sorunsuz ulaşabilmekteyiz.