|
|
Úvod
|
Extrémní velikost databáze služby Import uživatelských profilů
Před časem jsem řešil problém, kdy databáze služby Import uživatelských profilů měla velikost přes 21GB. To je na profily cca 150 členů domény poměrně dost. Začal jsem proto pátrat po tom čím by to mohlo být způsobeno a jak to vyřešit.
Prozkoumáním databáze (typicky ve svém jméně obsahuje UserProfile, její přesné jméno naleznete v konfiguraci služby Import uživatelských profilů) jsem zjistil, že drtivá většina dat se nachází v tabulce InstanceData. Tato tabulka slouží v průběhu importu. Problém je v tom, že se z ní nemažou nepotřebné záznamy z již proběhlých importů. Dokonce mezi uloženými procedurami můžete najít jednu, která se nachází ve schématu FIM a jmenuje se [TruncateInstanceData]. Je to dáno tím, že oproti předchozí verzi SP 2007, kde byl import omezen na Active Directory a byl řešen proprietárně, v SP 2010 je import řešen pomocí tzv. FIMu (Forefront Identity Manager). To je obecný nástroj pro distribuci informací z uživatelských profilů mezi různými systémy. Díky tomu může být zdrojem uživatelských informací i jiný informační systém, než jen Active Directory. Bohužel při implementaci FIMu (resp. jeho omezené části) do SharePointu došlo někde k chybě a zmíněná procedura se nevolá tak, jak by měla a nedochází k mazání již nepotřebných informací. Databáze proto roste a roste...
Řešením, které se nabízí, je ruční spuštění této procedury a její pravidelné spouštění. Protože ale procedura obsahuje jediný delete příkaz, může se vám stát, že po několika hodinách jejího běhu zjistíte, že skončila chybou a nedošlo ke zmenšení tabulky ani databáze. Je to proto, že elementární operace (např. DELETE) běží jako transakce. V průběhu transakce se vytváří log toho co se stalo, aby bylo možné případně transakci rollbackovat. Proto mazání velkého množství dat najednou vede k velkým nárokům na velikost databázového logu. Proto vám doporučuji následující:
- Změnte recovery schéma z Full na Simple. Tím docílíte toho, že po dokončení transakce se jí vygenerovaná část logu smaže.
- DELETE příkaz z procedury si vykopírute bokem a spouštějte několikrát za sebou s vhodnou podmínkou tak, aby množství mazaných záznamů nebylo příliš velké.
- Nakonec proveďte shrink databáze. Tím se uvolní prázdné místo po smazaných záznamech a dojde ke skutečnému zmenšení databázových souborů. To uděláte např. pomocí kontextového menu databáze v MS SQL Management Studiu. Zde najdete položku Tasks -> Shrink
- Přepněte recovery schéma databáze na původní hodnotu.
Protože jsem na webu narazil na informaci, že v některých databázích zmiňovaná procedura vůbec není, přikládám její podobu tak, jak jsem ji našel v mnou zkoumané databázi:
/****** Object: StoredProcedure [FIM].[TruncateInstanceData] */
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [FIM].[TruncateInstanceData]
AS
BEGIN
--************************************************************
--* *
--* Copyright (C) Microsoft. All rights reserved. *
--* *
--************************************************************
SET NOCOUNT ON;
DECLARE @truncationTime datetime;
SET @truncationTime = DATEADD(day, -1, GETUTCDATE());
DELETE FROM [dbo].[InstanceData]
WHERE ([created] < @truncationTime)
END
GO
20.2.2012 21:15:00
|
|
Odkazy z prohlížeče – 16.2.2012
CodeProject Hardware Lego NXT Windows Phone Ostatní
16.2.2012 21:58:53
|
|
Odkazy z prohlížeče – 9.2.2012
Codeproject HW - Reference Platform – hledal jsem něco k ovládání robota (NXT) pomocí MS Robotics Studio a našel jsem i přímo doporučenou platformu pro MSRS
- Jak na PID – podrobný přehled na mcu.cz – rovnice, vztahy, … (anglicky)
Ostatní
9.2.2012 20:39:52
|
GetPointAtFractionLength for Silverlight
Today I found nice implementation of GetPointAtFractionLength : http://www.charlespetzold.com/blog/2008/11/Text-on-a-Path-in-Silverlight.html (GetPointAtFractionLength method is part of .NET WPF framework, but isn't in Silverlight). May help, Thanks a lot Charles. Přidej do linkuj.cz! | jagg.cz! | del.icio.us! | digg it! | reddit! | kick it! | live it! | email it!...(read more)
8.2.2012 16:06:33
|
|
Odkazy z prohlížeče – 2.2.2012
Hardware Codeproject Ostatní
2.2.2012 17:10:11
|
Microsoft mě znechucuje čím dál více
Není tomu dávno, co jsem reagoval na situaci ohledně pravděpodobného směru vývoje Microsoftu. Dnes má trpělivost opět dosáhla mezních hranic, proto tento post. Vždy jsem byl zastáncem MS technologií, vývoj webových aplikací jsem začínal na klasických ASP a .NET pro mě byl poklad, kde vše oproti ostatním jazykům, jako Java, běží napoprvé a bezproblémů. Není nic tajného, že již delší delší dobu nejsem profesně čistě vývojář, ale táhne mě to více do projektového řízení. Díky tomu jsem měl cca 2 roky...(read more)
31.1.2012 10:14:00
|
ORA-12712 on NLS_CHARACTERSET changing from EE8MSWIN1250 to AL32UTF8
I tried to change character set in my oracle database because of Russian localization, I tried command: ALTER DATABASE CHARACTER SET AL32UTF8; i got this error: ORA-12712: new character set must be a superset of old character set After some googling I found solution, below are the commands executed by me: SQL> SHUTDOWN IMMEDIATE; SQL> CONNECT SYS/password AS SYSDBA; SQL> STARTUP MOUNT; SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION; SQL> ALTER DATABASE OPEN; SQL> ALTER DATABASE CHARACTER...(read more)
27.1.2012 11:37:11
|
AjaxControlToolkit.Binary.NET4
I have fond some unresolved issue in last ASP.NET Ajax Control Toolkit project. I tried use calendar extender with fallowing result: The requested script resource 'Common.Common.js' requires version 'AjaxControlToolkit, Version=4.1.51116.0, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e' of the ASP.NET AJAX Framework. To use this resource, make sure that the application references version 'AjaxControlToolkit, Version=4.1.51116.0, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e'. I wasn’t able...(read more)
26.1.2012 11:26:04
|
ora-12154 tns could not resolve the connect identifier specified
Issue : Cant connect from Visual Studio to Oracle DB on Windows 64 bit system Solution : Move Visual Studio from Program Files (x86) to Program Files folder Reason : Oracle driver doesn't accept parenthesis in working path Přidej do linkuj.cz! | jagg.cz! | del.icio.us! | digg it! | reddit! | kick it! | live it! | email it!...(read more)
24.1.2012 14:31:00
|
|
Omezení výběru uživatelů v dialogu výběru uživatelů
Celé to začalo podivným chováním úkolů v SharePointu. Jeden uživatel (říkejme mu třeba Karel Novák) měl přiřazeno několik úkolů. O všech mu přišla notifikace, že mu byly přiřazeny, ale některé nemohl měnit z důvodů nedostatku práv. Prostředí bylo nastaveno tak, že právo měnit úkol měl pouze přiřazený uživatel a zadavatel úkolů. Zběžná kontrola úkolů neodhalila nic podezřelého. Oba zkoumané úkoly vypadaly na vlas stejně. Práva byla nastavena automatickým procesem a taky byla stejná. Tedy alespoň na první a druhý pohled. Nakonec jsem si všiml, že problém byl v tom, že není Karel Novák jako Karel Novák. I když byl ve firmě jediný. On totiž měl 2 loginy v různých doménách se stejným jménem. Díky tomu se v dialogu pro výběr uživatele zobrazoval 2x. Pokud ale zadavatel úkolu zadal přesné jméno už v dialogu úkolu a stiskl Ctrl+K tedy ověření, tak ověření prošlo. Ale který z těch dvou účtů byl vybrán, to už se zadavatel nedozvěděl.
Naštěstí s tímto problémem při vývoji SharePointu počítali, takže se dá omezit, ze kterých organizačních jednotek se mají nabízet uživatelé při výběru uživatelů.
Dá se určit organizační jednotka AD, na kterou se má omezit výběr uživatelů:
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url http://ServerName
Taky se dá určit, že
- při ověřování jména uživatele (tlačítko Kontrola jmen, nebo Ctrl+K) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:
stsadm -o setproperty –pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection –pv yes –url
<Web application URL>
- ve vyhledávacím dialogu (tlačítko Procházet) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:
stsadm -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url
<Web application URL>
Pokud potřebujete něco sofistikovanějšího, můžete výběr uživatelů z AD omezit pomocí LDAP dotazu:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv
<LDAP query filter>
-url
<Web application URL>
Kompletní popis najdete na MSDN.
Při praktickém použití je ale nutné udělat ještě jednu věc. Samotné omezení výběru z Active Directory nestačí. Pokud totiž uživatel (resp. jeho login) už v SharePointu figuruje, např. proto, že mu byl přiřazen úkol, práva ... , je v seznamu uživatelů SharePointu. Jako takový je do výsledku vyhledávání v PeoplePickup editoru taky zahrnut, ať už výše uvedeným omezením vyhovuje, nebo ne. Proto je nutné, k tomu abyste se takového loginu zbavili uplně, odstranit ho i z tohoto "seznamu". S tím souvisí další trik. Standardně se totiž k seznamu všech uživatelů pomocí webového UI SharePointu nedostanete. Lze zobrazit jen členy určité skupiny. K tomu slouží stránka s adresou http://server/_layouts/people.aspx?MembershipGroupId=XXX. Parametrem XXX je ID té skupiny. Pokud použijete 0, dostanete seznam všech uživatelů bez ohledu na to členy jakých skupin jsou (pokud vůbec nějakých).
19.1.2012 22:30:00
|
|