Tartalom mozgatás WSS-ben

Bár a Windows SharePoint Services 3.0-ban már nincsenek igazán komoly korlátok a tartalom mennyiségére vonatkozóan az egyes listákban, dokumentumtárakban és webhelyeken, mégis van néhány olyan szám, amit érdemes szem előtt tartani. A Microsoft például nem javasolja 2000-nél több elem tárolását egy listában, 20GB-nál nagyobb webhely gyűjtemények és tartalom adatbázisok létrehozását vagy éppen 50MB-nál nagyobb fájlok tárolását. Akit érdekel a téma, a Plan for software boundaries című cikkben talál hasznos információkat, külön tudom ajánlani a Guidelines for acceptable performance fejezetet.

Ezen cikk apropóját az adja, hogy a tanszéki intraneten bizony belefutottunk a 20GB-os tartalom adatbázis korlátba az egyik webhely gyűjteményen. Íme néhány kérdés, válasz és workaround, ami ilyenkor felmerül az emberben:

1. Hogyan lehet egy listát vagy dokumentumtárat átmozgatni egyik webhelyről a másikra?

Ha a mérete nem túl nagy, akkor ki kell menteni sablonként tartalommal együtt, majd a lista sablontárból letölteni a sablont, átvinni a másik webhely lista sablontárába és az alapján ott létrehozni az új listát.

Vigyázat: saját tapasztalatom az, hogy az összekapcsolt listák (amelyben egy oszlop másik listában lévő oszlopra hivatkozik) nem jönnek át tökéletesen, gyakorlatilag újra kell definiálnunk a hivatkozó oszlopot és Excellel átvinni a tartalmat. Ez szívás.

2. Hogyan lehet egy nagy dokumentumtárat egyik webhelyről átmozgatni másik webhelyre?

Gondban vagyunk, ha a doktárban nagy fájlok vannak, mert a sablon mérete nem haladhatja meg a 10MB-ot. Ez szívás, nincs rá GUI és az stsadm se tudja. A fájlokat át lehet vinni WebDAV-on keresztül, a metaadatokat pedig Excelen keresztül.

3. Hol lehet megadni/megváltoztatni, hogy egy webhely gyűjtemény melyik tartalom adatbázisban tárolódjon?

Sehol. Ez is szívás.

4. Mi alapján dől el, hogy egy új webhely gyűjtemény melyik tartalom adatbázisban jön létre?

Na, ezt szépen bedrótozták a fejlesztők. Egy újonnan létrehozott vagy backupból visszaállított webhely gyűjtemény abban a tartalom adatbázisban jön létre, amelyben több a hely. A "több hely" a webhelyek számára vonatkozik. Amelyik tartalom adatbázisban nagyobb az alábbi delta, ott fog létrejönni:

delta = Webhelyek maximális száma - Webhelyek száma (jelenleg az adatbázisban)

A fenti képlet változói a Központi felügyelet > Alkalmazáskezelés > Tartalom-adatbázisok oldalon találhatóak meg. Emiatt tessék korlátozni a webhelyek számát a tartalom adatbázisokban, különben összevissza jönnek létre a webhelyek!

5. Hogyan lehet egy webhelyet egyik tartalom adatbázisból átvinni másik tartalom adatbázisba?

Erre sincs GUI és az stsadm se tudja. Miután megértettük, mi alapján dől el, hogy egy webhely gyűjtemény melyik tartalom adatbázisban jön létre, már tudjuk, hogy nincs más dolgunk, mint:

  1. stsadm segítségével backupot készíteni az adott webhely gyűjteményről.
  2. Készíteni egy új tartalom adatbázist és a többinek úgy állítani a korlátait, hogy ennek legyen a legnagyobb a deltája.
  3. Letörölni az eredeti webhelyet.
  4. Visszaállítani a mentést stsadm-mel, ami magától a jó helyen jön létre.
  5. A tartalom adatbázisok korlátait úgy módosítani, hogy a jövőben webhelyek a megfelelő adatbázisban jöjjenek létre.

6. Hogyan lehet egy tartalom adatbázis kettéválasztani?

Túl nagy lett, jó lenne szétosztani. Sajnos ez sem fog menni egyszerűen. Meg kell találni, hogy melyik a nagy méretű webhely gyűjtemény, azt le kell menteni, majd vissza kell állítani másik útvonalra, másik tartalom adatbázisba. Mivel ebben a fázisban ugyanaz a tartalom két példányban van meg, nincs más dolgunk, mint a tartalom felét innen, a tartalom másik felét onnan kitörölni.

7. Kitöröltem egy nagy méretű dokumentumtárat, de nem csökkent a tartalom adatbázisom mérete. Mi a gond?

Gond egy szál se, a WSS 3.0-ban már van Lomtár, ki kell üríteni.

8. Kiürítettem a Lomtárat, de még mindig nem csökkent a tartalom adatbázisom mérete. Mi a gond?

Gond egy szál se, a WSS 3.0-ban már van Lomtár, mégpedig kétszintű: felhasználó és webhely rendszergazda szintű. Mindkettőt ki kell üríteni.

9. A lomtár kiürítésekor vagy webhely törlésekor 0x80040E14 hibát kapok, meg egy semmitmondó Ismeretlen hiba üzenetet. Mi a gond?

Az Ismeretelen hiba valóban semmitmondó, a 80040E14 viszont Syntax error in INSERT INTO statement, tehát egyáltalán nem ismeretlen, csak ijesztő. Talán ezért nem merik megmutatni az átlagfelhasználónak? Rosszul írták meg a WSS-t?! A jelek szerint ez egyszerű timeout esetén következik be, ha túl nagy mennyiségű adatot próbálsz egyszerre törölni.

Ha nagy a webhely, próbálj doktáranként törölni előbb. Ha nagy a doktár, próbálj kisebb méretű mappákat vagy fájlokat külön törölni, vagy ne egyben az egész lomtárat kiüríteni, akkor menni fog. Nálam egy egygépes környezetben 3GB körüli doktárakat tudtam törölni gond nélkül, nagyobbakat nem.

Megjegyzem a WSS 2.0-ban is volt hasonló probléma a nagy mappákkal (lásd KB827930).

10. Backup visszaállításakor valami .tmp fájlra vonatkozó írási hibát kapok. Mi a gond?

Érdemes megnézni a SharePoint nyomkövetési naplóját, ami a C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS mappában található. A naplózás beállításait a Központi felügyelet > Tevékenység > Diagnosztikai naplózás oldalon találjuk meg. Itt a .log fájlokban kutatva megtalálhatjuk az írási hibaüzenetet, például:

Írási hiba a(z) "wss0CFC021441D14DE580F5B9B698AA34D5_1.tmp" fájlon.

Rögtön az előtte lévő sorban találunk egy 0x80070070 hibakódot, amire ha rákeresünk megtudhatjuk, hogy a kevés szabad helyre utal:

Error 80070070: There is not enough space on the disk.

Elsőre kicsit érthetetlen, hiszen amikor elindítottuk a visszaállítást, akkor jó sok hely volt, most meg nincs semmilyen wss....tmp fájl a diszken.

Kicsit feljebb olvasva a logban rájöhetünk a dolog nyitjára: a restore művelet az stsadm-et futtató felhasználó saját temp mappájába ír. Ha nem hagyjuk ott a visszaállítást egyedül futni, hanem folyamatosan szugeráljuk a szabad helyet, akkor azt fogjuk látni, hogy nem az adat partíciónkon, hanem a C:-n fogy el a hely!

A megoldás: át kell tenni az aktuális felhasználó Temp mappáját másik partícióra. Hogyan? My Computer > Properties > Advanced > Environment variables és ott írjuk át a TEMP és TMP értékét egy másik partíción lévő mappára. Visszaállítás végeztével ne felejtsük el visszaírni!

Egyébként pedig a visszaállítás idejére lehet, hogy célszerű kikapcsolni a WSS nyomkövetési naplózását, mert nálam például több száz MB logot írt. Kikapcsolni legegyszerűbben úgy lehet, ha leállítjuk a Windows SharePoint Services Tracing (SPTrace) szolgáltatást.

 

Nekem a fenti tapasztalatok összegyűjtése nagyjából 2 napot vett el az életemből. Egy nem túl fürge szerveren ennyi idő alatt sikerült egy 25GB-os tartalom adatbázist kettévágni és a tartalmát két új adatbázisba áttenni. Az én konfigurációmon a backup kb. 2,5-3 óra volt, a törlési hibaüzenetek pedig fél-háromnegyed óra alatt jöttek elő, ami után persze kezdhettem elölről :(  Remélem másnak már nem fog ekkora gondot okozni és még talán szeretni is fogja a SharePointot.



Balássy György (MS RD, ASP.NET MVP, MCTS)

Balássy György (MS RD, ASP.NET MVP, MCTS) Villamosmérnök, a BME Automatizálási és Alkalmazott Informatikai Tanszékén webportálok fejlesztését oktatja. 2000 óta foglalkozik a Microsoft .NET platformjával, melynek meghonosításában jelentős szerepet vállalt előadóként, konzulensként és A .NET Framework és programozása című könyv társszerzőjeként. Az MSDN Kompetencia Központon belül a Portál Technológiák Csoport vezetője, szakterülete web alapú rendszerek fejlesztése és üzemeltetése. 2004-ben Magyarországon elsőként kapta meg a Most Valuable Professional címet, majd 2005 óta a Microsoft magyarországi regionális igazgatója. Publikációi a Technet Magazinban, az MSDN Kompetencia Központ honlapján és szakmai blogjában olvashatóak.

2007.08.03. 20:31:35 | Permalink | Hozzászólások: 0 | Tárgyszavak:


  • Az Excel 2007 adatbányászati bővítményeinek használata - screencast

    Balássy György (MS RD, ASP.NET MVP, MCTS) Az Excel 2007-hez ingyenesen letölthető Data Mining Add-ins for Microsoft Office 2007 nevű kiegészítés segítségével a felhasználók az SQL Server Analysis Services mélyebb ismerete nélkül, varázslók támogatásával, a megszokott Excel környezetben oldhatnak meg adatbányászati feladatokat. Tovább »
  • Rendezésről ismét

    Kovács Ferenc Ha már az előző bejegyzést a rendezésnek szenteltem, gondoltam írok még egy kicsit róla. Ez nem SQL Server 2012 újdonság, csak most találkoztam vele. Lehet olyan agymenésünk (vagy a megrendelőknek), hogy egy lekérdezés eredményét egy mező értékétől függően eltérően kell rendezni. Például a nőket ABC sorrendbe szeretnénk látni, a férfiakat is ABC sorrendben de csökkenő irányban, vagy esetleg a férfiakat meg beosztások szerinti sorrendbe szeretné látni. Ekkor jön jól, hogy lehet CASE kifejezést használni az order by listán. Nézzük azt ha különböző rendezés irányokat szeretnénk használni. Tovább »


Írja meg Ön is véleményét!


Hozzászólásokat csak regisztrált, bejelentkezett felhasználóktól tudunk elfogadni!

Hozzászólások