Sürücüler ve Bağlama Noktaları?

Önceki Kıdemli DBA, şirketteki her SQL Server'daki tüm sürücülerimiz için bağlantı noktaları oluşturdu. Yeni Kıdemli DBA , standartlarımızı değiştirmek isteyen bağlama noktalarından dehşete düştü (esas olarak, bence, onlarla hiçbir deneyimi yok).

Çok sayıda internet aramasının sonuçlarına dayanarak, bağlanma noktaları kullanmamak için herhangi bir (SQL Server 2000 sonrası) neden bulamıyorum.

Bu konuyla ilgili Windows işletim sistemi sınırlamalarının farkında olan var mı?

• Son zamanlarda "İşletim Sistemi bağlantı noktalarını tanımıyor" iddiasını duyuyorum. (Doğru, kullandığımız Windows Server sürümleri üzerine yaptığım araştırmaya dayanarak).

Bağlama noktalarını SQL Server ile birlikte kullanmamak için kanıta veya deneyime dayalı bir sebep var mı?

• Sürücü harflerinin bitmesinin bizim için bir sorun olmadığını varsayın.

Benim görüşüme göre bağlama noktaları iş yüklerini ayırmada inanılmaz derecede faydalı.

Bağlama noktalarının farklı veri ve günlük dosyalarının (sistem veritabanı dosyaları, kullanıcı veritabanı dosyaları, tempDB) iş yüklerini veri dosyaları, günlük dosyaları ve tempdb için her biri bir sürücüden daha verimli bir şekilde ayırdığı / izole ettiği anlayışımı herkes onaylayabilir veya reddedebilir mi? ?

Montaj noktasının diğer ucunda ne olduğuna bağlıdır. Bağlantıların tümü LUNS ise aynı fiziksel sürücülere yayılmışsa, kazanç olmaz. LUNS'un tümü paylaşılan, yavaş, iSCSI kanalının üzerindeyse, belki kazanç olmaz. LUNS 1 denetleyicinin altındaysa ... kaç değişkenin oynadığını görürsünüz. Kimsenin cevabı yok.

Bağlama noktalarının yapılandırmasını belirlemek için bkz . Boe Prox tarafından PowerShell Kullanarak Bağlama Noktalarını Bulma .

SQL Server'ın bağlantı noktalarında bir sorunu yoktur. Bunlar işletim sistemi düzeyinde tanımlanır ve SQL Server " ^1'i bilmez", takılı oldukları sürücü ile aynı birim değildir.

Bununla birlikte, bazı İzleme araçları bu son cümleyi temel alarak size kötü bilgiler verebilir.

Örneğin, aşağıdaki üç bağlama noktanız varsa

1. C:\SQLData\SQL_Data tüm .MDB dosyalarınızın saklandığı yer
2. C:\SQLData\SQL_Logs tüm .LDF dosyalarınızın saklandığı yer
3. C:\SQLData\SQL_Backups Burada tüm .BAK ve .TRN yedek dosyalarınız depolanır

Sonra SQL Server sorunsuz çalışacaktır. Ancak, disk alanı az olduğunda sizi uyaran bir tür araç çalıştırırsanız, altındaki C: ve altındaki birimleri değil , dolayısıyla bu bağlama noktalarının disk alanı azaldığını bilemeyebilirsiniz. Ayrıca, çeşitli "en iyi uygulamalar" sorguları, SQL Server'ın aynı diskte olduğunu düşündüğü için verileriniz, günlükleriniz ve yedeklemelerinizin hepsinin aynı diskte olmaması gerektiğini bildiren yanlış uyarılar atar . Bunlar sahte bayraklardır ve göz ardı edilebilir.

Ancak temel olarak, C: sürücüsünde yeterli alan olduğundan ve her bağlama noktasının da olduğundan emin olmak için sunucu izlemenizde bazı ek adımlar ayarlamak istersiniz .

SQL Server'da bağlama noktaları kullandığım zamanlar, karşılaştığım tek sorun buydu: Boş alan hakkında yanlış veriler veren SQL Server sistem durumu raporları ve tüm verilerinize sahip olmamalısınız diyerek yanlış hatalar aynı sürücüde. Bunların yanlış hatalar olduğunu bildiğiniz için, görmezden gelmeleri kolaydır.

¹ SQL Server, bağlama noktasından haberdar olan verilere sahiptir, ancak pratik kullanım açısından, davranışta bir fark yoktur. "Sadece çalışır," işletim sistemi özelliklerini işlemek için güveniyor. Tıpkı yerel sürücüler olarak bağlı iSCSI LUN'ların özelliklerini işlemesi için işletim sistemine güvenmesi gibi.

CM_Dayton en ilaveten cevap ve Sean Gallardy en cevabı henüz Dağı Points ile özdeşleşmiş değil bir konu güvenliği ile ilgilidir. Bağlama Noktası Klasörlerinde SQL İzinlerini Ayarlama Yönergeleri'ni alıntılamak için :

Bağlama noktası kök klasörleri normal klasörler gibi görünmesine ve klasörlere aynı şekilde erişilmesine rağmen, bunlar normal klasörler değildir. Sonuç olarak, bir bağlama noktası kök klasöründe izinleri ayarladığınızda, izinler "üst birimden" normal klasörlerle aynı şekilde miras alınmaz. Aslında, hiç miras kalmazlar. Bunun nedeni, bağlanan birimin "ana birimin" alt öğesi olduğu görülmesine rağmen değildir. Takılı birime "ana birim" den bir yolla erişiyorsunuz.

Özetle, bağlama noktası kök klasörünü kullanmak istiyorsanız Mount Klasörlerine farklı izinler atamanız gerekir. Normal bir klasörde yaptığınız gibi izinler atamak yerine, birime izin atamanız gerekir. Yine, aynı makaleden (vurgu Microsoft'tur):

Sorunlar

Ne yazık ki, Windows Gezgini aracılığıyla bağlama noktası kök klasöründe izinleri ayarlamak / görüntülemek hala mümkündür, bu da bağlama noktası kök klasörünün izinleri geçerli görünebileceğinden ve "uygun" devralınan izinleri görebildiğiniz için beklenmedik sonuçlara yol açabilir ancak bunlar, bağlanan birime uygulanan izinler değildir.

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

Kuralları

1. Doğrudan bağlanma noktası kök klasörüne herhangi bir dosya yerleştirmemeniz önerilir . Bu, izin yönetimini daha basit hale getirecektir, çünkü eğilim her zaman klasör izinlerini kontrol etme eğilimindedir, bu durumda yanıltıcıdır. Bunun yerine, bağlama noktası kök klasörünün altında bir alt klasör oluşturun ve bu alt klasöre uygun izinleri ayarlayın . Alt klasör normal bir klasör olduğundan, gözlemlediğiniz ve ayarladığınız klasör izinleri gerçekten de uygulanan izinlerdir. Bu nedenle, önceki örneği kullanarak yeni bir klasör oluşturmak istersiniz: D: \ FolderForVol3 ** SubfolderXYZ **. Şimdi, klasör izinlerinizi normalde yaptığınız gibi yeni SubfolderXYZ klasörüne ayarlayın.
2. Öğeleri doğrudan doğrudan bağlama noktası kök klasörüne yerleştirmeniz gerekiyorsa (Önerilen yaklaşım değil), klasör izinlerini değil birim izinlerini ayarlamanız gerekir. Bunun, bağlama noktası kök klasörü izinlerinin gerçekte bağlı birimde ayarlanacak izinler olmaması (hatırlama noktası kök klasörü gerçek bir klasör olmadığı için) olduğunu hatırlayın. Birim izinlerini aşağıdaki gibi ayarlayabilirsiniz:
   • Start-> run-> diskmgmt.msc (Birimin özelliklerini görüntüleyin http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Birim-> Özellikler-> Güvenlik sekmesini seçin
3. SQL'in kullanması için yeni bir klasör ekliyorsanız, SQL erişimi için gerekli izinlere dikkat edin:
   • SQL Server 2012 ile başlayan izinler, hizmetlerinin her biri için hizmet başına SID'ye atanır. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Windows Hizmet Hesaplarını ve İzinlerini Yapılandırma http://msdn.microsoft.com/en-us/library/ms143504.aspx

MS'in önerdiği gibi Bağlama Noktası altındaki bir alt klasördeki her şeyi yuvalamak istemiyorsanız, izinleri atamanın en kolay yolunu bulacağınız cacls.exeyardımcı programdır. Bununla ilgili ayrıntılı yönergeler , Windows Server 2003'te NTFS dosya sistemi biriminin kök dizinine izinleri uygulayamıyorsunuz bölümünde bulunabilir .

Henüz tam olarak çözülmüş bir konu olduğunu sanmıyorum. Bu son soru Mount Point izin sorunları ile SQL Server FCI yüklemesi , SQL Server 2016 ile Windows 2012'de hala olabileceğini göstermektedir.

Hangi güvenliğin atanmasını istediğinize bağlı olarak, komut değişebilir, ancak test başarının anahtarıdır, bu nedenle \Ebayrak gibi basit bir şeyi unutursanız güvenliği hızlı bir şekilde yapabileceğiniz için canlı bir bağlama noktasına karşı çalıştırmadan önce komutla tanışın .

Çok sayıda internet arama sonuçlarına dayanarak bağlanma noktaları kullanmak için herhangi bir (SQL Server 2000 sonrası) neden bulamıyorum.

Bunun ana nedeni, birinin onlarla kötü bir deneyimi olması (veya tersine, onlarla hiçbir deneyiminin olmaması) ve onları tamamen bitirmesidir ... sonsuza dek. Bu, kişisel tercih olarak bilinir.

Şimdi, orada olan bunları kullanamadı bazı nedenler. Düşünebilmemizin bir numaralı nedeni, bir 3. taraf sürücünün veya uygulamanın / aracının (filtre sürücüsü, disk çoğaltması vb.) Bunu desteklememesidir. Bunun hızlı bir örneği, NTFS dışında hiçbir şeyi desteklemeyen, yalnızca belirli küme boyutlarıyla ve belirli bir birim için 2 TB'ın üzerine çıkamayan bir blok düzeyinde disk çoğaltma aracıdır.

Bu konuyla ilgili Windows işletim sistemi sınırlamalarının farkında olan var mı?

Hayır, çok sayıda montaj noktası yapabilirsiniz. Aslında, Windows Server'ın içinde kayda değer bir sınıra ulaşmadan önce genellikle cihaz arayüzlerinizle ilgili bir sorun yaşarsınız (17 yaşından büyük bir Windows Server sürümü kullanmadığınız varsayılarak ...).

• Son zamanlarda "OS montaj noktalarını tanımıyor" iddiasını çok duyuyorum. (Doğru, kullandığımız Windows Server sürümleri üzerine yaptığım araştırmaya dayanarak).

İşletim sistemi bağlama noktalarını tanımıyorsa, bir bağlama noktası kullanmanıza nasıl izin verirdi? Bu hiç mantıklı değil.

İşletim sistemi bağlama noktalarını tanımıyorsa, neden bunları izler ve meta verilerini sorgular ? Ayrıca, bir bağlama noktasının, bir işletim sisteminin destekleyebileceği veya destekleyemeyeceği dosya sisteminin bir yapısı olduğunu lütfen unutmayın. Geldiğiniz tüm dosya sistemleri bağlama noktalarını desteklemeyebilir, ancak Windows Server'daki en yaygın dosya sistemi aslında bağlama noktalarını destekleyen ve bir süredir sahip olan NTFS'dir .

Bu yanlış ürünü daha da ileriye götürmek için; Windows Kümelemesi, birimler için bağlama noktaları kullanan Küme Paylaşılan Birimleri (CSV'ler) adlı bir şeye sahiptir ... bu, teknolojiyi kullanan yerel bir öğedir. Söylemeliyim ki, size bunu kim söyledi, bu konuda eğitilmelidir.

Bağlama noktalarını SQL Server ile birlikte kullanmamak için kanıta veya deneyime dayalı bir sebep var mı?

Evet, her zaman Windows NT 4 çalıştıran bir sunucu vardır ... orada kullanmayın. Ayrıca Windows Server'ın desteklenen bir sürümünü çalıştırdığınızdan ve güncellemelerden haberdar olduğunuzdan emin olmak isteyebilirsiniz .

Ancak, yukarıda açıkladığım gibi, desteklenmeyen veya onlarla düzgün çalışmayan 3. taraf öğeleri olabilir. O sağlayıcıyı bırak ve yeni bir tane bul diyebilirim.

Benim görüşüme göre bağlama noktaları iş yüklerini ayırmada inanılmaz derecede faydalı.

Montaj noktaları inanılmaz derecede faydalıdır. Bunları kullanmanın birçok yolu vardır, en yaygın olanı Windows'un sürücü harfi sınırlamalarını (olduğu gibi, sadece çok fazla vardır) aşmaktır. Bir sonraki en yaygın kullanım, delicesine büyük ve nadiren yönetilebilir monolit birimlerinden kurtulmanıza yardımcı olmak için daha küçük yönetilebilir boyutlu sürücülere (LUN'lar, sanal disk [VMDK, VHDX]) sahip olmaktır (10 TB aralığındaki sürücüleri yönetmek gerçekten bir sorun haline gelir tek bir LUN, sanal disk vb.) özellikle uygulamanın olası kullanımdan daha az olduğu eski NTFS sürümlerinde ... örneğin, Windows'un eski sürümlerinde maksimum NTFS boyutu 2 TB'dı.

İş yükü ayrımı bir başka harika kullanımdır. Kesinlikle görebilirsiniz, birçok kullanım var ve bu bireysel kullanım durumunuza bağlıdır. Bunu kullanmanın uygunsuz yolları da var ... her şeyin bir bağlantı noktası olması gerektiğine dair kapsamlı bir açıklama yapmak gibi. Bu noktada sadece çılgın idari yük.

Bağlama noktaları, paylaşılan uygulamaları olan sunucular için veya verileri tipik DZ birimlerinden daha fazla dilimlemenin yoludur.

Örneğin, örneğin e:sürücüye tüm uygulama verilerini, günlük ve geçici dosyaları yükleyebilirsiniz . E:/MP_1Business A için veri dosyaları E:/MP_2olabilir, günlük dosyaları E:/mp_3Business A için geçici dosyaları olabilir vb. Daha sonra F:Drive'daki bağlantı noktalarında Business B var . Her bağlama noktasının kendi alanı vardır.

İşletim sisteminin MP'lerle kesinlikle hiçbir sorunu yoktur. Kümelerin ve Daima Açık durumunun MP'lerle ilgili bir sorunu yoktur. SQL Server'larının çoğunun MP'lerde yüklü olduğu çok iyi bilinen bir bankada çalıştım. DBA bunları kullandıktan ve kavramları anladıktan sonra, ihtiyacı olan dükkanlarda daha kolay çözümlere yönlendirecektir.

MP köküne herhangi bir şey yüklememesinden bahsedildi. Bu doğru. MP kökü gibi hiçbir şey, örnek olarak D köküne hiçbir şey yüklemez.

Foglight, Guardiam, EMS ve PBM gibi denetim ve izleme çözümlerinin de montaj noktalarıyla ilgili bir sorunu yoktur.