SQL Server Arşiv

Deleting RBS (Remote Blob Storage) Data on Disk (SharePoint)

There are two options to store your content data of your applications on your Microsoft SharePoint environment.

Default

This option stores the files uploaded to the site as binary content in content database tables. With this option active, default settings of SharePoint recycle bin will be in use when deleting content. These settings — described in details below — keeps the deleted content in content database and enables you to restore it even after 60 days (default value is 30 + 30 days).

RBS (Remote Blob Storage)

Remote Blob Storage is a whole other subject and we will focus on some of the problems we face on this subject. To learn more about RBS, I recommend reading this article: https://docs.microsoft.com/en-us/sharepoint/administration/rbs-overview

If I have to briefly explain, it is about storing binary BLOB data which is stored in content database by default outside of content database. In the case where RBS is used, default recycle bin in SharePoint works the same way, however in addition to the default setting of 30 + 30 days, garbage collection process of RBS must be performed. Otherwise, deleted SharePoint content will continue to take up space on the disk.

RBS (Remote Blob Storage) Verisinin Disk Üzerinden Silinmesi (SharePoint)

Varsayılan

RBS (Remote Blob Storage)

Workflow Manager Server Migration

Workflow Manager Server yüksek ölçekli, yüksek yoğunluklu iş akışlarını barındırmak için kullanılmakta olan bir teknolojidir. Bildirim tabanlı (declarative) bir modelde geliştirme yapmanıza izin verir. Yani geliştirdiğiniz iş akışlarında kod barınmaz, sadece deklerasyonları barınır. Arka plan sistemleri ile servisler üzerinden haberleşerek iş mantığının akışa uygulanması amaçlanır. Microsoft .Net Framework 4.5 ve Windows Workflow Foundation üzerinde inşa edilmiştir.

Workflow Manager’ın genel kullanımı Microsoft SharePoint Server üzerinde SharePoint Workflow’larını çalıştırmaya yöneliktir. Aslında Workflow Manager, SharePoint için yaratılmış bir yapı değildir ancak genel kullanımına baktığımızda ağırlıklı olarak SharePoint ürünü ile beraber kullanıldığını gözlemliyoruz.

Topolojik olarak bir farm mantığında çalışır. Yani tıpkı SharePoint veya Exchange Server farmlarında olduğu gibi ilk sunucu kurulumundan sonra bir farm yapılandırması gerçekleştirirsiniz. Ardından yeni sunucular üzerinde de uygulama kurulumlarını yaparak oluşturduğunuz bu farma ekleyebilirsiniz. SharePoint özelinde bahsedecek olursak, ayrı bir sunucu olmadan doğrudan SharePoint Server kurulu olan sunuculara da kurulum gerçekleştirebilirsiniz. (Ancak önerilmez)

Workflow Manager hakkında kısa bir özetten sonra bu yazıda değinmek istediğim konuya gelmek isterim. Tüm sunucu uygulamalarında olabileceği gibi farklı nedenlerle Workflow Manager’I da mevcutta konfigüre edildiği sunucu üzerinden farklı bir ortama taşımak isteyebilirsiniz. Nedenleriniz aşağıdakilerden biri olabilir;

  • Mevcut ortamda yaşanan sıkıntılar sonrasında in-place düzeltme işlemlerini yapamıyor ve yeniden kurulum yapmak istiyor olabilirsiniz.
  • Alınan mimari bir karar sonrası Workflow Manager’I ayrı bir farm olarak değerlendirmek istiyor olabilirsiniz.
  • Bir felaket senaryosu sonrası elinizde sadece güncel Workflow Manager veritabanları kalmış olabilir ve yeni bir yapılandırma ile çalışmalarınıza devam etmek istiyor olabilirsiniz.
  • Kurulu bulunan ortamda Windows upgrade, domain upgrade/change, vb sistemsel altyapı çalışmaları yapılacak olması sebebiyle konfigürasyonu yenilemek istiyor olabilirsiniz.

Bu nedenleri artırmak mümkün. Temel olarak bir uygulamanın yeniden kurulması ve konfigüre edilmesi çok ciddi bir sorun gibi görünmüyor. Ancak sözkonusu olan iş akışlarını barındıran Workflow Manager gibi bir yapı olduğunda önemli olan konulardan biri de iş sürekliliği. Mevcut kurulumunu üzerinde yaygınlaştırılmış olan onlarca iş akışınız ve bu iş akışlarının SharePoint liste ve kütüphaneleri ile ilişkili binlerce devam örneği (instance) olabilir. Elbette ne tüm akışlarınızı yeniden yaygınlaştırmak isteyeceksiniz ne de devam eden örnekleri kaybedip tüm örnekleri yeniden başlatmayı. Bu noktada sağlıklı bir ortam kurmak ve mevcut yapının bu ortam üzerinde devam eden örnekleri ile beraber çalışmasını sağlamak önem taşıyor.

Bu işlemi gerçekleştirmek için öncelikle ön gereksinimlerimizi tanımlamamız gerekiyor.

RBS Blob Verisini Dosya Sisteminden Silememe Problemi

SharePoint ortamınızda uygulamalarınızın içerik bilgisini saklamak için SQL Server Remote Blob Storage (RBS) özelliğini kullanıyorsanız yaşamış olacağınız bir problem dosyaların SharePoint ortamından silinmesine rağmen dosya sisteminde yani diskinizde herhangi bir kullanım azalması olmamasıdır. Biraz daha açacak ve genel olarak SharePoint’in çöp kutusu mekanizmasına da bakacak olursak;

Bildiğiniz üzere SharePoint altyapınızda iki kademeli bir çöp kutusu mekanizması yer almaktadır. Bir kütüphaneden sildiğiniz bir dosya öncelikle ilgili sitenin çöp kutusuna taşınır. Varsayılan olarak burada kalma süresi 30 gündür ki bu değer Central Administration aracılığı ile değiştirilebilir. 30 günlük sürenin geçmesinin ardından eğer dosyayı restore etmediyseniz bu defa site koleksiyonunun çöp kutusuna taşınır. Ve yine varsayılan bir ayar olarak 30 gün de burada kalır. Ve ardından artık dosya tamamen silinir. Çöp kutusunda kaldığı süre içerisinde elbette bir soft delete işleminden bahsediyoruz. Dosya sadece silinmiş olarak işaretlenmekte ve restore komutunuz ile aynı şekilde geri alınabilmektedir. Buraya kadar varsayılan bir SharePoint sisteminin davranış şeklini inceledik. Eğer RBS kullanıyorsanız işte tam bu aşamada dosyanın halen blob storeda saklanmakta olduğunu, diskten silinmediğini gözlemleyebilirsiniz. Tabi bunu genelde tek bir dosya silme işleminde hissetmeyiz. Genellikle problemin farkına vardığımız an diskimizin sürekli dolması ve yüklü dosya silme işlemlerimizin ardından bile diskte bir azalma olmadığı zamanlardır.

SQL Server Sunucusunu Sonradan Domaine Almak

Daha çok test veya geliştirme ortamı senaryosu olabilir ancak yine de hiçbir zaman karşımıza çıkmayacağını düşünebileceğimiz kadar masum olmayan konulardan biridir bir sunucuyu yazılımsal işlemler sonrası aktif dizine (domain) almak. Canlı ortamlarında elbette gerekli kurumların bir ön gereksinimidir sunucunun aktif dizinde olması ama yukarıda da bahsettiğim gibi test veya geliştirme ortamlarında veya klonlanmış sanal ortamlarda sunucu adını değiştirmek, sunucuyu aktif dizine almak daha sık gerçekleştirilir.

Aktif dizin yokken konfigürasyonu yapılan bir yazılım, sunucu aktif dizine alındıktan sonra çok farklı davranabilir. Ben bu ufak bilgilendirme yazısında SQL Server üzerinden gitmek istiyorum. Sunucuyu SQL Server kurulumu sonrasında aktif dizine almayı denerseniz karşılaşacağınız temel senaryo şu şekildedir.

  • Named-Pipes protokolü “Disabled” duruma gelmiştir.
  • SQL Server Management Studio‘ya bağlanamazsınız.
  • SQL Server servisleri durmuştur ve başlatamazsınız.

Bu durumun üstesinden gelmek için öncelikle “SQL Server Configuration Manager” ile “Named-Pipes” ı yeniden “Enable” duruma getirin. Ardından Management Studio’ya bağlanamama ve servislerin başlamama sebebi olan kullanıcılarınız yetkisi kısmına geliyoruz. Aktif dizinden önce lokal hesaplarınız sunucuda yönetici rolündeydi ama artık lokal hiçbirşey kalmadı. O halde yeni kullanıcılarınıza hak vermeniz lazım. Bunun için bilinen en kısa yol Management Studio ve oraya erişiminiz yok. Öncelikle bir uyarı, aktif dizine alma işlemi öncesi sunucuda “SQL Server and Windows Authentication” özelliğini aktif hale getirin ve geçici de olsa “sa” kullanıcısına hak verin ki aktif dizine girdiğinizde yeni kullanıcılarınıza hak vermek için sisteme bağlanabilin.

Ama diyelim ki bu yazıyı okuduğunuzda iş işten geçmişti, o halde “SQLCMD” ye merhaba diyelim. Aşağıda yer alan komutlar ile SQLCMD üzerinden yeni kullanıcılarınıza hak verebilir ve hem SQL Server Management Studio erişimi hem de servislerinizin yeniden çalışmaya başlamasını sağlayabilirsiniz.

 

Hata: Failed to update database “DBNAME” because the database is read-only

Kodladığınız uygulamanız içerisinde, bir batch işlemi çalıştırırken veya bir SSIS paketini çalıştırdığınızda, yani veritabanı üzerinde yazma işlemi yapmak istediğiniz herhangi bir zamanda bu hata ile karşılaşabilirsiniz.

“Failed to update database “DBNAME” because the database is read-only”

Yaptığınız kontrollerde database’in read-only modda olmadığını gözlemlemiş olabilirsiniz. Bunun için pek çoğunuzun bildiği üzere management studio üzerinden ilgili veritabanı ismi üzerinde sağ tıklamanız ve özellikler ekranında “Options” bölümüne gelmeniz ve en alta inmeniz yeterli. Burada “Read-Only” özelliğinin “False” olmasını bekliyoruz. “True” ise zaten hatanın sebebi açıkça ortadadır. Değeri değiştirmeniz yeterli olacaktır.

Biz bu bölümün “False” olmasına rağmen hatayı aldığımızı varsayalım. Bu durumda yapmanız gereken kontroller için aşağıdaki kod bloğunu kullanabilirsiniz. “AdventureWorks” örnek olarak kullanılmıştır. Bu bölümde kendi veritabanı isminizi verebilirsiniz.

 

 

Son olarak SQL Server Express versiyonunu kullananlar için bir ek hatırlatma. Burada AttachDbFileName kullanıyorsanız SQL Server servis hesabınızın Connection String’de belirttiğiniz dosya yoluna erişim ve yazma için izni olduğundan da emin olmalısınız.

Hata: SSIS Access Denied

SQL Server Integration Services kurulumunu yapmanızın ardından kurulum aşamasında servis hesabı olarak verdiğiniz kullanıcı ile bile SSIS instance’ına bağlantı kurarken aşağıdaki şekilde yetki hatası alabilirsiniz.

“Connecting to the Integration Service on the computer ”[SERVERNAME]’ failed with the following error. Access is denied”

Esas olarak SQL Server Integration Services kurulumlarında varsayılan olarak server administrator grubu yetki sahibidir ancak bazen bu kullanıcı ile bile yetki hatası alabilir ve SSIS instance’ına bağlantı sağlayamayabilirsiniz. Bu durumda aşağıdaki adımları takip etmek işinize yarayacaktır. (SQL Server 2014 ve SQL Server 2016 için test edilmiştir)

  • Component Services ekranını açın. Bunun için Start > Run  kısmına “dcomcnfg” yazarak ilerleyebilirsiniz.
  • Sol bölümdeki panelden Computers > My Computer > DCOM Config bölümüne kadar gelin.
  • Burada “Microsoft SQL Server Integration Services 12.0” (Bu SQL Server 2014 için, SQL Server 2016’da versiyon numarası 13.0 olacaktır)
  • Üzerinde sağ tıklayarak “Properties” > “Security” tabına gelin ve ekrandaki bölümlere istediğiniz yetki seviyelerine göre kullanıcınızı veya grubunuzu ekleyin.
  • İşlemden sonra SQL Server Integration Services servisini yeniden başlatın.

Bazen buna rapmen yetkilendirmede sorun yaşıyor olabilirsiniz. Bu durumda ek bir adım olarak aşağıdakini de uygulayabilirsiniz.

  • Server Manager > Computer Management > Local Users and Groups > Groups kısmında “Distributed COM Users” grubunu bulun ve kullanıcınızı buraya ekleyin.