A Max fokozat párhuzamosság (DOP) egy fejlett SQL Server konfigurációs lehetőség, amely számos kérdés tárgyát képezte, és számos publikáció témája volt. Ebben a blogbejegyzésben a szerző azt reméli, hogy némi világosságot ad arról, hogy mit tesz ez a lehetőség, és hogyan kell használni.

Először is a szerző szeretné eloszlatni azokat a kétségeket, amelyek afelől, hogy a fenti opció beállítja, hogy az SQL Server hány processzort használhat több kapcsolat (vagy felhasználó) kiszolgálásakor – ez nem így van! Ha az SQL Server négy tétlen processzorhoz fér hozzá, és úgy van beállítva, hogy mind a négy processzort használja, akkor a párhuzamosság maximális fokától függetlenül mind a négy processzort használja.

Tehát mit csinál ez az opció? Ez a beállítás beállítja az SQL Server által egyetlen lekérdezéshez használható processzorok maximális számát. Ha az SQL Server lekérdezésének vissza kell térnie nagy térfogatú adatok (sok rekord), néha érdemes párhuzamosítani azokat több kis lekérdezésre bontva, amelyek mindegyike a saját sorainak részhalmazát adja vissza. Így az SQL Server több processzort is használhat, és így többprocesszoros rendszereken is nagyszámú a teljes lekérdezés rekordjai gyorsabban visszaküldhetők, mint egy egyprocesszoros rendszeren.

Számos feltételt kell figyelembe venni, mielőtt az SQL Server meghívja az "Intra Query Parallelism"-t (egy lekérdezés több szálra terjesztése), és nincs értelme ezeket itt részletezni. Megtalálhatja őket a BOL-ban, ha rákeres a "Degree of parallelism" kifejezésre. Azt mondja, hogy a párhuzamosításról szóló döntés a processzor rendelkezésére álló memória és különösen maguknak a processzoroknak a rendelkezésre állásán alapul.

Ezért érdemes megfontolni ennek a lehetőségnek a használatát, mert az alapértelmezett értéken hagyva (az SQL Server maga dönt a párhuzamosításról) néha nemkívánatos hatásokkal járhat. Ezek a hatások így néznek ki:

• A párhuzamos lekérdezések lassabban futnak.
• A lekérdezés végrehajtási ideje nem determinisztikussá válhat, és ez bosszantahatja a felhasználókat. A végrehajtási idő változhat, mert:
  • Egy lekérdezés néha párhuzamosítható, néha pedig nem.
  • Egy kérés blokkolható párhuzamos kéréssel, ha a processzorok korábban túlterheltek voltak.

Mielőtt folytatnánk, a szerző szeretné megjegyezni, hogy nincs különösebb szükség a párhuzamosság belső szerveződésébe merülni. Ha érdekli ez, elolvashatja a Books on Line "Párhuzamos lekérdezésfeldolgozás" című cikkét, ahol ezeket az információkat részletesebben bemutatjuk. A szerző úgy véli, hogy csak két fontos dolgot kell tudni a párhuzamosság belső szerveződéséről:

1. A párhuzamos kérések több szálat hozhatnak létre, mint amennyi a „Maximális párhuzamossági fok” beállításban szerepel. A DOP 4 több mint tizenkét szálat tud létrehozni, négyet lekérdezéshez, és további szálakat rendezésekhez, szálakhoz, aggregátumokhoz és összeállításokhoz stb.
2. A lekérdezések párhuzamossága eltérő SPID-várakozást okozhat CXPACKET vagy 0X0200 várakozási típus esetén. Ezzel megkereshetjük azokat a SPID-ket, amelyek párhuzamos műveletekre várnak, és a rendszerfolyamatokban a várakozási típusuk: CXPACKET. A feladat megkönnyítésére a szerző a blogjában elérhető tárolt eljárás használatát javasolja: track_waitstats.

És így "A lekérdezés lassabban futhat párhuzamosan" miért?

• Ha nagyon gyenge a rendszer áteresztőképesség lemezes alrendszereket, akkor a lekérdezés elemzésekor annak felbontása tovább tarthat, mint párhuzamosság nélkül.
• Lehetséges adatferdítés vagy adattartomány zárolás a processzornál, amit egy másik párhuzamosan használt és később elindított folyamat generál stb.
• Ha nincs index a predikátumhoz, ami táblázatvizsgálatot eredményez. A lekérdezésen belüli párhuzamos műveletek elrejthetik azt a tényt, hogy a lekérdezés sokkal gyorsabban futna szekvenciális végrehajtási tervvel és megfelelő indexszel.

A párhuzamosság fent említett hatásai önmagukban arra a gondolatra vezethetnek, hogy a lekérdezések párhuzamosításának belső mechanikája nem alkalmas OLTP alkalmazásokban való használatra. Ezek olyan alkalmazások, amelyeknél a lekérdezés végrehajtási idejének megváltoztatása bosszanthatja a felhasználókat, és amelyeknél egy sok felhasználót egyidejűleg kiszolgáló szerver valószínűleg nem választ párhuzamos végrehajtási tervet az alkalmazások processzorterhelési profiljának sajátosságai miatt.

Ezért, ha párhuzamosságot kíván használni, akkor valószínűleg adatkinyerési feladatokhoz (adattárház), döntéstámogató vagy jelentéskészítő rendszerekhez lesz szükség, ahol nincs sok lekérdezés, de meglehetősen nehézek, és egy nagy teljesítményű, nagy RAM-mal rendelkező szerveren futnak.

Ha a párhuzamosság mellett dönt, milyen értéket állítson be a DOP-nak?. Ennél a mechanizmusnál bevált gyakorlat, hogy ha 8 processzorunk van, akkor állítsuk be a DOP = 4-et, és nagy valószínűséggel ez az optimális beállítás. Arra azonban nincs garancia, hogy ez így fog működni. Az egyetlen módja annak, hogy megbizonyosodjon erről, ha teszteli a DOP különböző értékeit. Ezen túlmenően a szerző empirikus tanácsot kívánt adni, soha ne állítsa ezt a számot a rendelkezésre álló processzorok számának több mint felére. Ha a szerzőnek hatnál kevesebb processzora volt, a DOP-t 1-re állítja, ami egyszerűen letiltja a párhuzamosítást. Kivételt tehet, ha olyan adatbázissal rendelkezik, amely csak egyetlen felhasználói folyamatot támogat (egyes adatlekérési technológiák vagy jelentéskészítési feladatok), ebben az esetben kivételként a DOP értéke 0 (alapértelmezett), ami lehetővé teszi, hogy az SQL Server maga döntse el a lekérdezés párhuzamosítását.

A cikk befejezése előtt a szerző figyelmeztetni akarta, hogy az indexek párhuzamos létrehozása a DOP-hoz beállított számtól függ. Ez azt jelenti, hogy érdemes lehet módosítani az indexek létrehozásakor vagy újra létrehozásakor a művelet teljesítményének javítása érdekében, és természetesen használhatja a MAXDOP tippet a lekérdezésben, amely lehetővé teszi a konfigurációban beállított érték figyelmen kívül hagyását, és csúcsidőn kívül használható.

Végül a kérés lelassulhat párhuzamosításkor a hibák miatt, ezért győződjön meg arról, hogy a legújabb szervizcsomag telepítve van a kiszolgálón.

REATE proc track_waitstats
@num_samples int = 10
,@delaynum int = 1
,@delaytype nvarchar ( 10 )="perc"
MINT
-- T. Davidson
-- Ezt a tárolt eljárást =AHOGY VAN= biztosítjuk, garancia nélkül,
-- és konferenciáknak nincs joga.
-- A mellékelt szkriptminták használatára a feltételek vonatkoznak
-- a http://www.microsoft.com/info/cpyright.htm címen van megadva
-- A @num_samples a várakozási adatok rögzítésének száma,
-- az alapértelmezett 10-szer. alapértelmezett késleltetési időköz 1 perc
-- a késleltetési szám a késleltetési intervallum. a delaytype meghatározza, hogy
-- a késleltetési idő percek vagy másodpercek
-- hozzon létre waitstats táblát, ha nem létezik, ellenkező esetben csonkolja

állítsa nem számít rá
ha nem létezik (válassza ki 1 sysobjects-ből ahol name = "waitstats" )
tábla létrehozása waitstats(varchar( 80 ),
numerikus kérések ( 20 ,1 ),
numerikus ( 20 ,1 ),
numerikus ( 20 ,1 ),
most dátum és idő alapértelmezett getdate())
különben csonkolja a táblát a waitstats

dbcc sqlperf (waitstats,clear) -- a waitstats törlése

kijelenti @i int
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@most dátumidő
,@totalwait numeric ( 20 ,1 )
,@endtime datetime
,@begintime datetime
,@hr int
,@min int
,@sec int

válassza az @i = lehetőséget 1
válassza a @dt = kis- és nagybetűket (@késleltetési típus)
amikor "perc", akkor "m"
amikor "perc", akkor "m"
amikor "min" akkor "m"
amikor "mm", akkor "m"
amikor "mi" akkor "m"
amikor "m" akkor "m"
amikor "másodperc", akkor "s"
amikor "második" akkor "s"
amikor "sec" akkor "s"
amikor "ss" akkor "s"
amikor "s" akkor "s"
különben @delaytype
vége

ha @dt nincs benne ("s" "m" )
kezdődik
nyomtatás "kérjük, adja meg a késleltetés típusát, pl. másodperc vagy perc"
Visszatérés
vége

ha @dt = "s"
kezdődik
válasszon @sec = @delaynum % 60
select @min = cast((@delaynum / 60 ) mint int )
válassz @hr = cast((@min / 60 ) mint int )
válasszon @min = @min % 60
vége

ha @dt = "m"
kezdődik
válassza a @sec= lehetőséget 0
válasszon @min = @delaynum % 60
select @hr = cast((@delaynum / 60 ) mint int )
vége

select @delay = right("0" + convert(varchar( 2 ),@hr), 2 ) + ":" +
2 ),@min), 2 ) + ":" +
+ right("0" +convert(varchar( 2 ),@sec), 2 )

ha @hr > 23 vagy @min > 59 vagy @sec > 59
kezdődik
válassza ki "óó:mm:ss késleltetési idő nem lehet > 23:59:59"
válassza ki a "késleltetési intervallumot és írja be: " + convert (varchar ( 10 )
,@delaynum) + "," + @delaytype + " konvertál a következőre: "
+ @késés
Visszatérés
vége

miközben én<= @num_samples)
kezdődik
insert into waitstats(, requests,
,)
exec("dbcc sqlperf(waitstats)")
válassza az @i = @i + lehetőséget 1
várj késleltetésre @delay
vége

Hozzon létre várakozási jelentést
futtassa a get_waitstats parancsot

--//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/

CREATE proc get_waitstats
MINT
-- Ezt a tárolt eljárást =AHOGY VAN= biztosítjuk, garancia nélkül, és
-- konferenciáknak nincs joga.
-- A mellékelt szkriptminták használatára a megadott feltételek vonatkoznak
-- a http://www.microsoft.com/info/cpyright.htm címen
--
-- ez a procedúra a várakozási típusokat felsoroló várakozási statisztika jelentést hoz létre
-- százalék
-- futtatható, amikor a track_waitstats fut

állítsa nem számít rá

deklarálja a @most dátumidőt
,@totalwait numeric ( 20 ,1 )
,@endtime datetime
,@begintime datetime
,@hr int
,@min int
,@sec int

válassza a @now=max (most),@begintime=min (most),@endtime=max (most) lehetőséget
from waitstats ahol = "Összesen"

Vonja ki a waitfor, a sleep és a resource_queue értékeket a Totalból

válassza a @totalwait = sum() + lehetőséget 1 a waitstatsból
ahol nincs ("WAITFOR" "SLEEP" "RESOURCE_QUEUE"
, "Összesen" , "***összesen***" ) és most = @most

Korrigált összegek beszúrása százalékos csökkenő sorrendben

delete waitstats ahol = "***összesen***" és most = @most

illessze be a várakozási statisztikákba, válassza ki a "***összesen***" lehetőséget
,0
,@totalwait
,@totalwait
,@Most

válassza ki
,
,százalék = leadott ( 100 */@totalwait mint numerikus ( 20 ,1 ))
a waitstatsból
ahol nincs benne ("WAITFOR" "SLEEP" "RESOURCE_QUEUE" "Összesen" )
és most = @most
százalékos sorrendben desc

Ebben a rövid megjegyzésben szeretnék egy kicsit beszélni a Microsoft SQL Server párhuzamossági beállításainak bonyolultságáról. Sokan közületek már régóta ismerik a Max Degree od Parallelism opciót, amely már nagyon régóta jelen van az SQL Serverben. Alapértelmezés szerint 0-ra van állítva, ami azt jelenti, hogy az SQL Server maga választja ki a párhuzamosság optimális fokát, vagyis az egy utasítás végrehajtásában részt vevő processzorok/szálak számát. Nem fogok most megállni és megbeszélni, hogy milyen értékre célszerű ezt az opciót beállítani - ez egy külön megjegyzés témája. Csak azt vizsgálom, hogy ennek az opciónak az értéke hogyan befolyásolja a lekérdezések végrehajtását. Például az alábbi ábrán ez a beállítás 1-re van állítva, ami azt jelenti, hogy az összes lekérdezés párhuzamos tervei alapértelmezés szerint le vannak tiltva.

Ez az opció a következő T-SQL paranccsal is megtekinthető:

Valójában minden alapértelmezett lekérdezési terv szekvenciális lesz. Például:

A fejlesztőnek és bármely felhasználónak azonban továbbra is lehetősége van ezt befolyásolni tippek segítségével. Ehhez csak meg kell adnia a kívánt párhuzamossági fokot, és létrejön a kívánt lekérdezési terv, például:

És ha ezt a lekérdezést a sys.dm_exec_query_profiles nézeten keresztül figyeljük meg, látni fogjuk, hogy valóban 10 szálon keresztül fut le.

Így marad egy titkos lyuk a rendszerben, amivel a fejlesztők és a felhasználók „felgyorsíthatják” (itt szándékosan tettem idézőjelbe, mert a nagyfokú párhuzamosság nem mindig vezet a lekérdezés végrehajtási idejének csökkenéséhez) a párhuzamosság mértékének növelésével. De ily módon egyszerűen „megölhetik” a szervert azáltal, hogy sok ellenőrizetlen párhuzamos kérést indítanak egyszerre. Mit tehetünk ellene? Itt jön a segítség a Resource Governor, egy nagyon erős és teljesen alábecsült rendszer, amely lehetővé teszi az erőforrások nagyon rugalmas elosztását a különböző felhasználói csoportok között. Ismét nem foglalkozom azzal, hogyan működik és milyen képességekkel rendelkezik. Csak kifejtem, hogy a párhuzamossági limit beállításai hogyan hatnak rá. Először nézzük meg az alapértelmezett beállításokat:

Ismét azt látjuk, hogy az opció alapértelmezés szerint 0-ra van állítva, és a maximális fokozat megválasztása az SQL Server kegyén múlik. Most lássuk, mi történik, ha ezt az értéket 5-re változtatom. Még csak nem is definiáltam osztályozási funkciót a Resource Governor számára, és módosítom az alapértelmezett csoportot. De egy teszthez és annak megértéséhez, hogyan működik most minden a példámban, ez elég. Így a párhuzamosság maximális fokát mindenkinél 5 szálra korlátozom. Emlékezzen erre a lehetőségre Maximális párhuzamossági fok, amit korábban néztünk, továbbra is 1-re van állítva. Ha most megnézzük az eredeti lekérdezésünk végrehajtási tervét, akkor alapból szekvenciális lesz, a maxdop 10 opcióval pedig párhuzamos. De ha párhuzamos tervet futtatunk, akkor valami érdekeset fogunk látni.

Most a kérésünk csak 5 szálon hajtódik végre, annak ellenére, hogy az opció maxdopértéke 10. És ha megadja a 4-es maxdop opciót a lekérdezéshez, akkor a lekérdezés 4 szálban kerül végrehajtásra (a Resource Governor opció 5-re van állítva). Ebben az esetben a tipp maxdop kevesebb, mint az Erőforrás-irányító beállítás, így nincs további korlátozás. Erre már nem mondok példát.

Így a Resource Governor egy erősebb eszköz, amely már valóban korlátozza a lekérdezések maximális párhuzamossági fokát, és ez a fok a különböző felhasználói csoportokhoz eltérően állítható be. Ugyanakkor az opció Maximális párhuzamossági fok továbbra is működik és teszi a dolgát (vagy kissé összezavarja az adminisztrátorokat, fejlesztőket és felhasználókat, ha a Resource Governorral párosítják). Ezen túlmenően a két paraméter értékének beállítási lehetőségeinek csak a képzelet szab határt, de fontos megjegyezni, hogy csak két dolog: Maximális párhuzamossági fokés tipp maxdop egy kérés esetén befolyásolja, hogy melyik terv kerüljön generálásra, hány maximális szál lesz lehetséges ehhez a kéréshez, és a Resource Governor tovább korlátozza a kérést felülről már futás közben.

Cél: tanulmányozza az SQL párhuzamosság hatását az 1C lekérdezésekkel végzett munkára

Irodalom:

Tesztkörnyezet:

Windows Server 2008 R2 Enterprise

MS SQL Server 2008 R2

1C Enterprise 8.2.19.90

1. ábra: SQL tulajdonságok „General”

2. ábra: SQL tulajdonságok "Speciális"

Eszközök:

SQL szerver profilkészítő

Query Console 1C

Teszt kérés:

VÁLASZT

AK.Name AS Név

TÓL TŐL

Információk nyilvántartása Címosztályozó AS AK

BELSŐ ÖSSZEKAPCSOLÁS Információk nyilvántartása Címosztályozó AS AK1

SW AK.Code = AK1.Code

Készítmény:

Elindítjuk az SQL szerver Profilert, létrehozunk egy kapcsolatot, megjelöljük az eseményeket és az oszlopokat a 3. ábrán látható módon.

3. ábra Nyomkövetési tulajdonságok

Kiválasztás beállítása a bázisunkhoz

4. ábra: Szűrés adatbázis szerint

Rövidítések:

Maximális párhuzamossági fok – MDOP

Költségküszöb a párhuzamossághoz - költség

Szekvenciális lekérdezési terv tesztelése (MDOP = 1)

5. ábra: Query Console – 20 másodperces végrehajtási idő

Az SQL-kiszolgáló „Maximális párhuzamossági foka” paraméter 1-re van állítva (nincs párhuzamosság). Megnézzük az eredményt a profilozóban (6. ábra)

6. ábra: Szekvenciális lekérdezési terv

Az SQL szerver szekvenciális lekérdezési tervet generált, miközben: teljes CPU terhelés = 6,750 (mp), a lekérdezés végrehajtási ideje = 7,097 (mp)

Párhuzamos lekérdezési terv tesztelése (MDOP = 0, költség = 5)

Az SQL szervert párhuzamos módba helyezzük (SQL Queryben):

USE master ;

EXEC sp_configure "show advanced option" , 1;

ÚJRAKONFIGURÁLÁS AZ OVERRIDE-VEL

USE master ;

exec sp_configure "max. párhuzamossági fok" , 0;

ÚJRAKONFIGURÁLÁS AZ OVERRIDE-VEL

Ugyanazon lekérdezés végrehajtása (7. ábra)

7. ábra: Query Console – 16 másodperces végrehajtási idő

Az eredmény ellenőrzése a profilozóban (8. ábra)

8. ábra Párhuzamos lekérdezési terv

Az SQL szerver ezúttal párhuzamos lekérdezési tervet alkotott, a teljes CPU terhelés = 7,905 másodperc, a lekérdezés időtartama = 3,458 másodperc

Szekvenciális lekérdezési terv tesztelése (MDOP = 0, költség = 150)

Próbáljunk meg megszabadulni a párhuzamos tervtől a "Költségküszöb a párhuzamossághoz" paraméterrel. Alapértelmezés szerint a paraméter 5-re van állítva. Esetünkben sikerült megszabadulni a 150-es értékű párhuzamos terv kialakításától (SQL Queryben):

USE master ;

exec sp_configure "költségküszöb a párhuzamosságért", 150 ;

Ilyen feltételek mellett ellenőrizzük a kérés teljesítését (9. ábra)

9. ábra: Query Console – 20 másodperces végrehajtási idő

Ellenőrizzük az eredményt a profilozóban (10. ábra)

10. ábra: Szekvenciális lekérdezési terv.

Az SQL Server szekvenciális lekérdezési tervet hozott létre. Teljes CPU-használat = 7,171 mp, lekérdezés végrehajtási ideje = 7,864 mp.

Következtetések:

Egy tesztlekérdezés végrehajtása 1C Enterprise környezetben SQL szerver párhuzamos lekérdezési terv használatával jelentős teljesítménynövekedést ad a szekvenciális tervhez képest (16 mp vs. 20 mp - nyereség 4 mp)

Maga az SQL Server tesztlekérdezés-végrehajtása párhuzamos lekérdezési terv használatakor kétszer olyan gyors, mint soros lekérdezési terv esetén (3,5 másodperc vs. 7,1 másodperc)

Az SQL szerver párhuzamossága nem csak az MDOP paraméterrel állítható be, hanem a „Cost threshold for parallelism” paraméterrel is

• oktatóanyag

Ez az útmutató azoknak a kezdőknek szól, akik egyszerű orosz nyelvű útmutatót keresnek az SQL Server 2012 angol verziójának telepítéséhez, amelyet a SharePoint 2013-hoz használunk.
Ez a cikk nem szakembereknek szól.

Minden munka 3 szakaszra oszlik:

• Az SQL Server 2012 telepítése
• A párhuzamosság maximális fokának beállítása a kiszolgáló konfigurációs beállításában
• A SharePoint 2013 telepítéséhez szükséges fiók jogainak konfigurálása

A cikk ismerteti a Microsoft .NET-keretrendszer 3.5-ös telepítésének folyamatát is MS Windows Server 2012 R2 Standard rendszeren.

Figyelem: a vágás alatt sok kép van!

Az SQL Server 2012 telepítése

1. Telepítés előtt ellenőrizze, hogy van-e elegendő szabad hely a merevlemezen (esetemben 2,7 GB-ot vett igénybe).
A terjesztési készlet elindítása után válassza ki a " Telepítés" a bal oldali menüben, majd "kattintson" az elemre " Új SQL Server önállóan, vagy adjon hozzá funkciókat egy meglévő telepítéshez":

2. A telepítővarázsló elindul. Ő ellenőrizni fogja. A "Részletek megjelenítése" gombra kattintva megtekintheti a részletes jelentést:

3. Részletes jelentés. Nyomja meg az "OK" gombot:

4. Írja be a termékkulcsot, és kattintson a "Tovább" gombra:

5. Egyetértünk a licencszerződés feltételeivel.
Ehhez jelölje be a négyzetet Elfogadom a licenc feltételeket

6. A "Setup Role" lépésben válassza ki az első elemet " SQL Server szolgáltatás telepítése". Nyomja meg a "Tovább" gombot:

7. A „Funkció kiválasztása” lépésnél jelölje be a „ Adatbázismotor-szolgáltatások", "Kezelőeszközök – Basic"És" Kezelőeszközök – teljes". Ezután kattintson a "Tovább" gombra:

8. A telepítő ezután újabb ellenőrzést hajt végre. A "Részletek megjelenítése" gombra kattintva megtekintheti a részletes jelentést:

9. Részletes jelentés. (Ebben a szakaszban hibaüzenetet kaptam a "Microsoft .NET Framework 3.5 telepítve van..." szabályban. Erről lentebb olvashat bővebben). Nyomja meg a "Tovább" gombot:

10. A "Példány konfigurálása" lépésben konfigurálnia kell az SQL Server szolgáltatás példányát.
Ez a cikk ismét a kezdőknek szól. Ezért feltételezzük, hogy az SQL Server korábban nem volt telepítve a szerverére, ami azt jelenti, hogy minden alapértelmezett beállítást meghagyunk. Nyomja meg a "Tovább" gombot:

11. Ebben a lépésben a telepítővarázsló megjeleníti a lemezterület követelményeit. Nyomja meg a "Tovább" gombot:

12. A "Szerver konfigurálása" lépésben meg kell adnia egy tartományfiókot a " szolgáltatáshoz SQL Server Database Engine". A "Fióknév" és a "Jelszó" mezők kitöltése után kattintson a "Tovább" gombra:

13. Az "Adatbázismotor konfigurálása" lépésnél elegendő az aktuális felhasználót hozzáadni az SQL szerver rendszergazdáihoz. Ehhez kattintson a "Jelenlegi felhasználó hozzáadása" gombra, majd kattintson a "Tovább" gombra:

14. A következő lépésben kattintson a "Tovább" gombra:

15. Ezután a telepítővarázsló újra elvégzi a tesztet, és megjeleníti annak eredményeit. Nyomja meg a "Tovább" gombot:

16. A "Telepítésre kész" lépésnél a varázsló összefoglaló információkat jelenít meg. Itt a "Telepítés" gombra kell kattintani:

17. A telepítés befejezése után a végrehajtott műveletekkel kapcsolatos információk jelennek meg:

18. Erősen ajánlom, hogy ebben a szakaszban indítsa újra a számítógépet. Bizonyos esetekben (például a Microsoft .NET-keretrendszer 3.5 telepítésekor) maga a telepítővarázsló is megjelenít egy ablakot, amely a számítógép újraindítását kéri. Ne add fel.

A párhuzamosság maximális fokának beállítása a kiszolgáló konfigurációs beállításában

A "Maximális párhuzamossági fok" paraméter alapértelmezett értéke 0.
A SharePoint 2013 használatához ennek a beállításnak 1-nek kell lennie.
Könnyen javítható!

1. Fuss Microsoft SQL Server Management Studio(Start – Minden program – Microsoft SQL Server 2012 – SQL Server Management Studio).

2. A szerverkapcsolat képernyőn kattintson a Csatlakozás gombra.

3. Kattintson jobb gombbal a szerverére a " Object Explorer" és válassza a " Tulajdonságok":

4. A megnyíló szerver tulajdonságai ablak bal oldali menüjében válassza ki a " Fejlett" és görgesd a tulajdonságok listáját a képernyő aljáig. Állítsa be a paraméter értékét " Maximális párhuzamossági fok"V 1 és kattintson az "OK" gombra:

5. Ne zárja be az SQL Server Management Studio-t, továbbra is szükségünk lesz rá.

A SharePoint 2013 telepítéséhez szükséges fiók jogainak konfigurálása

A fióknak, amelyre a SharePoint 2013 telepítve lesz, magasabb szintűnek kell lennie az SQL Serverben.
Javasoljuk, hogy ezt a fiókot a következő szerepkörökkel ruházza fel:

• dbcreator
• securityadmin
• nyilvános

1. Az SQL Server Management Studio programban a " Object Explorer"elem kibontása" Biztonság". Ezután kattintson jobb gombbal a " Bejelentkezések" és válassza a " Új bejelentkezés":

2. A „Bejelentkezési név” mezőben adja meg annak a fióknak a tartománynevét, amelyen a SharePoint 2013 telepítését és konfigurálását tervezi.

3. A bal oldali menüben válassza a "" oldalt Szerver szerepkörök", és ellenőrizze a "dbcreator" és a "securityadmin" szerepkört, és győződjön meg arról, hogy a "public" szerepkör már be van jelölve. Ezután kattintson az "OK" gombra:

Az SQL Server készen áll a SharePoint 2013 telepítésére.

A Microsoft .NET Framework 3.5 telepítése MS Windows Server 2012 R2 Standard rendszeren

A " bekezdés 9. lépésében Az SQL Server 2012 telepítése" Hibaüzenetet kaptam: A .NET Framework 3.5 nincs telepítve.
A probléma megoldásához kövesse az alábbi lépéseket:

1. Meg kell nyitnia a konzolt " szerver menedzser".

2. A bal oldali menüben válassza ki az „Irányítópult” elemet.

3. Az ablak közepén kattintson a "Szerepek és szolgáltatások hozzáadása" elemre.

4. A megnyíló varázslóban hagyja ki a „Before Begin” lépést.

5. A "Telepítés típusa" lépésnél válassza a " Szerep alapú vagy szolgáltatás alapú telepítés Nyomja meg a „Tovább” gombot.

6. A következő lépésben hagyjon mindent alapértelmezettként, és kattintson a "Tovább" gombra.

7. Hagyja ki a „Kiszolgálói szerepkörök” lépést a „Tovább” gombra kattintva.

8. A "Features" lépésnél jelölje be a ".NET-keretrendszer 3.5 szolgáltatásai" jelölőnégyzetet. Megnyomjuk a "Tovább" gombot.

9. A telepítési folyamat befejezése után bezárhatja a Szerepkörök és szolgáltatások hozzáadása varázslót.

10. Kész!

Minden jó és békés ég a fejed felett!

P.S. Boldog űrhajós napot!

Ez a bejegyzés csak az MS SQL Serverre összpontosít. Ha „szerencsét próbál próbálni” az 1C használatában az Oracle, DB2, Postrgre segítségével, ezek az információk haszontalanok lesznek. De meg kell értenie, hogy az 1C-ben mindenekelőtt az MS SQL Server szakemberei vannak. Az IBM erőfeszítéseinek köszönhetően DB2-specialisták is vannak. Sokáig lehet beszélni jó vagy rossz DBMS-ről, egy dolog fontos, az MS SQL szerverrel a leg "simábban" működik az 1C. A „frontról” érkezett legújabb üzenetekből ítélve a DB2-vel végzett munka többé-kevésbé megfelelővé vált. Bár nekem személyesen volt tapasztalatom az 1C beállításában, hogy működjön együtt a DB2-vel a 8.1-es verzióban, ott valahogy nem volt minden túl jó. Mindenesetre a másik DBMS választását egyértelműen meg kell érvelni - vagy az MS SQL-ben nem szereplő lehetőségekkel (klaszter terheléselosztással, Griddel stb.), vagy a pénzügyekkel (az Oracle-t már megvették), vagy a platformmal (minden linuxon van).

Tehát, mit kell tenni az MS SQL Serverrel:

1) Állítsa be a minimális és maximális memóriát. A minimum a rendszermemória fele. Maximum - rendszermemória 2 GB nélkül. Ez a Management Studio segítségével történik - a szerver tulajdonságainál:

2) Ha a prioritás nincs beállítva a "Processzorok" lapon, be kell állítania

3) Állítsa a párhuzamosság maximális fokát 1-re.

4) Kapcsolja be az SQL Server Agent-et, állítsa be a Database Mail-t - nincs ott semmi nehéz, nem írom le részletesen.

5) Állítsa be a szolgáltatási terveket:
Gyakoriak:
a) Statisztikák frissítése – 2 óránként
b) DBCC FREEPROCCACHE - 2 óránként
Minden alaphoz:
a) Teljes biztonsági mentés
b) Differenciál biztonsági mentés
c) Index töredezettségmentesítés - minden nap
d) Index átépítés - hétvégi éjszakák
e) Az adatbázis sértetlenségének ellenőrzése - havonta egyszer, hétvégén éjszaka

6) Azt javaslom, hogy a helyreállítási modellt állítsa Egyszerűre minden adatbázishoz (a tulajdonságokban). Ha nincs éjjel-nappali rendszere, és bázisonként kevesebb, mint 1000 felhasználó, nincs feladatátvételi fürtje, és nem írt alá olyan SLA-t, amelyben vállalja, hogy bármely berendezés meghibásodása esetén (és nem az utolsó biztonsági mentés időpontjától) másodpercenként visszaállítja az adatokat, akkor ez az ajánlás ésszerű. Ellenkező esetben hamarosan hosszan és eszeveszetten gondolkodik, hová tegye a túlnőtt Tranzaction Log-ot

7) Távolítsa el a tempdb adatbázist a normál adatbázisokból egy másik lemezre – még akkor is, ha ez a RAID-tömb újrakonfigurálásával és teljesítményének csökkenésével jár. Ellenkező esetben 1 felhasználó képes lesz megbénítani az összes többi munkáját. Ha merevlemez helyett Hardveres gyorsítód van, akkor természetesen nem tudod szétválasztani és rátenni a tempdb-t, de ez csak akkor van, ha van

8) Telepítsen valamilyen megfigyelő eszközt - például szeretem a spotlightot: http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Tesztelje magát a Microsoft bevált gyakorlatok elemzőjével - http://www.microsoft.com/download/en/details.aspx?id=15289 - egy nagyszerű eszköz, amely nemcsak a beállításokban, hanem számos probléma megoldásában is segít.

Dióhéjban, miért tettük mindezt:

1) Memória. A minimális érték egyszerűen megkíméli Önt a "hibáktól", amikor az SQL-kiszolgáló valamilyen okból, amelyet csak ő ismer, nem használja ki az összes rendelkezésére álló memóriát. Meg kell enni az egészet! A maximális érték megkíméli a cserét, ha ugyanaz az SQL szerver memóriahasználat-optimalizáló úgy dönt, hogy nem ártana...

3) Egy nagyon fontos pont - az IHMO-t minden tranzakciós rendszerben 1-re kell állítani. Először is, megakadályozza, hogy a különböző folyamatok között egyes zárolások 1 kérést próbáljanak végrehajtani, és ennek megfelelően megkímél minket néhány "furcsa" hibától. Másodszor... 1 "gyilkos" kérés képes lesz átvenni a szerver összes erőforrását, ami némileg igazságtalan a rendszer többi felhasználójával szemben.A paraméter maga határozza meg, hogy hány processzormag tud feldolgozni 1 kérést.

5) A statisztikáról és az eljárási gyorsítótár törléséről - ez "hallásra", de gyakran elfelejtjük az újraindexelést. Eközben ez az eljárás meglehetősen fontos, különösen az adatbázis mennyiségének növekedésével nő a jelentősége. Néha a teljesítmény akár 60%-a is elveszik az index töredezettsége miatt.

7) Ha Hardvergyorsítóval vagy csak 2 különböző hozzáférési sebességű lemezzel rendelkezik, akkor azt is javaslom, hogy gondolkodjon el az adatbázisokban lévő fájlcsoportok kiosztásán, és az egyes táblák felosztását különböző lemeztömbökbe, különböző hozzáférési időkkel. Végül is egyetért abban, hogy a PH "áruk a raktárakban" és a "Kiegészítő információk tárolása" kézikönyv 2 olyan objektum, amelyek tárolási követelményei alapvetően eltérőek. Nem szükséges az adatbázisban található összes fájlt és képet egy gyors tömbön tárolni - külön is szétválaszthatod, nem olyan gyorsan, de ahol sok a hely (és mellesleg ne félj egy csomó fájlt később feltölteni az adatbázisba).