Archive for Oktober, 2010

Fast Search Vorschaubilder über SSL

Sandra Erb

 

Die neue Fast Search für SharePoint bietet viele neue Funktionen, u.a. eine Vorschau von Dokumenten. Für Word Dokumente wird die erste Seite angezeigt, für PowerPoint kann sogar die gesamte Präsentation als Preview eingesehen werden.

Läuft die SharePoint Seite unter SSL wird man statt mit der Preview, jedoch mit einem JavaScript Fehler begrüßt.

JavaScript Error

Der Fehler betrifft nur die Vorschaubilder, während alle anderen Features der Fast Search anscheinend problemlos funktionieren.

Die Details des Fehlers lauten ungefähr wie folgt:

Meldung: Syntaxfehler
Zeile: 2
Zeichen: 1
Code: 0
URI:
https://meinSharePoint.oraylis.de/personal/documents/_vti_bin/wacproxy.ashx?redirect=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%2Fdocuments%2F_layouts%2FWordViewer.aspx
%3Fid%3D2Fpersonal%2Fdocuments%2FShared%2520Documents%2F
Der%2520ORAYLIS%2520Test.docx%26DefaultItemOpen%3D1&spsite=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%

2Fdocuments&docType=docx&zone=undefined&callbackFunctionName=
DelegateFn_SRB_g_3897520d_8fa6_4997_88c8_5ac1f1b642a5_5

Um den Fehler zu lösen muss das Root-Zertifikat nicht nur am Server selbst und im IIS installiert werden, sondern auch noch einmal explizit in die SharePoint Trusts aufgenommen werden.

Hierzu in der SharePoint Central Administration in den Bereich Security wechseln und die Seite Manage trust aufrufen.

image

Hier auf New klicken und das Root Zertifikat hinzufügen.

image

Der JavaScript Fehler verschwindet sofort und auch die Vorschaubilder werden bei der nächsten Suche angezeigt. Sollte der JavaScript Fehler behoben sein, die Vorschaubilder jedoch nicht angezeigt werden, heißt es ein wenig Geduld haben. Die Dokumente müssen erst gecached werden.

image

  • Share/Bookmark

SharePoint 2010 Fehler – Event ID 7362 Publishing Cache Warnung

Sandra Erb

Der Object Cache wird vom Publishing Feature genutzt und speichert Eigenschaften von verschiedenen SharePoint Elementen. Das Ziel des Object Caches ist es u.a. die Last des SQL Servers zu reduzieren. Mehr Informationen zum Object Cache gibt es unter http://technet.microsoft.com/en-us/library/ff758656.aspx.

Wurden die Standardeinstellungen des Object Caches übernommen und das Publishing Feature in einer Applikation aktiviert, so wird in regelmäßigen Abständen die folgende Warnung ins Windows Event Log geschrieben:

Event ID: 7362

Log Name:          Application
Source:               Microsoft-SharePoint Products-Web Content Management
Date:                  11.10.2010 12:03:30
Event ID:           7362
Task Category: Publishing Cache
Level:                 Warning
Keywords:
User:                  <SharePoint System Account>
Computer:          <SharePoint Server>
Description:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
Additional Data:
Current default super user account: SHAREPOINT\system

Ursache

Standardmäßig wird der SharePoint Systemaccount als Cache Super User Account eingetragen. Allerdings sollte dieser für jede Webapplikation, welche das Publishing Feature verwendet, auf zwei Domänenbenutzer aufgeteilt werden.

Warum zwei Benutzer?

Der Object Cache führt seine Abfragen als einer von zwei Benutzern aus, entweder als “Super User”, welcher vollen Zugriff auf alle Objekte im SharePoint hat (so z.B. auch auf Dokumente, welche noch den Status “Entwurf” haben), oder als “Super Reader”, welcher nur Zugriff auf veröffentlichte Objekte hat. Führt ein Benutzer nun z.B. eine Suche aus, so werden die Ergebnisse aus dem Cache angezeigt. Je nach dem, über welche Berechtigungen der Benutzer selbst verfügt, werden ihm entweder die Ergebnisse des “Super Users” oder des “Super Readers” angezeigt.

Lösung

Im Active Directory müssen zwei neue Benutzeraccounts angelegt werden. Diese Accounts benötigen keine besonderen Rechte oder Gruppenzugehörigkeiten. Die beiden Accounts sollten ausschließlich als Cache Accounts verwendet werden und niemals dafür die SharePoint Seite über den Browser aufzurufen.

Um die Benutzer nun richtig zu konfigurieren gibt es verschiedene Möglichkeiten. Diese Schritte müssen für alle Webapplikationen durchgeführt werden müssen, welche das Publishing Feature verwenden.

Variante 1: Central Administration und Power Shell

  1. In der SharePoint 2010 Central Administration im Bereich Application Management die Seite Manage web applications öffnen.
  2. Den Namen der Webapplikation auswählen, für welche die Konfiguration vorgenommen werden soll.
  3. Aus dem Web Applications Tab die Option User Policy auswählen.
  4. Im “Policy for Web Application” Fenster auf “Add Users” klicken.
  5. Als Zone “All zones” auswählen und auf “Next” klicken.
  6. Den Namen des Super User Accounts eintragen und als Berechtigung “Full Control – Has full control” auswählen.
  7. Auf “Finish” klicken und auf die selbe Art und Weise den Super Reader Account hinzufügen. Als Zone wieder “All zones” wählen und als Berechtigung “Full Read – Has full read-only access” einstellen.
  8. Eine Power Shell/SharePoint 2010 Management Konsole öffnen die folgenden Befehle ausführen:
    $wa = Get-SPWebApplication -Identity "<Name oder URL der WebApplication>"
    $wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
    $wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"
    $wa.Update()

    Hierbei ist wichtig, dass die Namen der beiden Benutzer Accounts in der selben Schreibweise angegeben werden, wie sie im Fenster “Policy for Web Application” angezeigt werden.

Tipp: Die oben gezeigten Befehle können auch als Power Shell Skript (.ps1 Datei) gespeichert werden.

Variante 2: Power Shell

Muss die Einstellung für mehrere Applikationen vorgenommen werden, lohnt sich die Automatisierung über ein Power Shell Script.

$webapp = Get-SPWebApplication –Identity http://webapp

# Reader Account registrieren und berechtigen
$rdrcred = New-SPManagedAccount –Credential (Get-Credential)
$rdrpol = $webapp.Policies.Add($rdrcred.Username, $rdrcred.Username)
$rdrpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullRead”)) 

# Writer Account registrieren und berechtigen
$wrtcred = New-SPManagedAccount –Credential (Get-Credential)
$wrtpol = $webapp.Policies.Add($wrtcred.Username, $wrtcred.Username)
$wrtpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullControl”)) 

# Accounts zuweisen
$webapp.Properties["portalsuperuseraccount"] = $wrtcred.Username
$webapp.Properties["portalsuperreaderaccount"] = $rdrcred.Username 

$webapp.Update()

Variante 3: Central Administration und STSADM

Für alle, die sich noch nicht mit der PowerShell auseinander gesetzt haben, gibt es die Möglichkeit die Benutzer auch über stsadm zu konfigurieren. Ich lege allerdings jedem SharePoint 2010 Administrator ans Herz sich schnellstmöglich mit der Power Shell vertraut zu machen, da stsadm in Zukunft von dieser abgelöst wird.

  1. Die Schritte 1 bis 7 aus dem Abschnitt “Variante 1: Central Administration und Power Shell” ausführen, um die Benutzer der Web Applikation zuzuordnen.
  2. Die nachfolgenden stsadm Befehle für jede Webapplikation ausführen:
    stsadm -o setproperty -propertyname portalsuperuseraccount
                          -propertyvalue "<SuperUser>" -url "<http://webapp>"
    stsadm -o setproperty -propertyname portalsuperreaderaccount
                          -propertyvalue "<SuperReader>" -url "<http://webapp>"  
  • Share/Bookmark

MS SQL Server 2008 SP2 veröffentlicht

Daniel Snellen

 

Am 29.09.2010 hat Microsoft das Servicepack 2 für den SQL Server 2008 veröffentlicht.
Der SQL Server hat nach dem Einspielen des SP die Version 10.00.4000.00.

Auf dieser Webseite kann das Servicepack heruntergeladen werden:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8fbfc1de-d25e-4790-88b5-7dda1f1d4e17&displaylang=en

Dieses SP ist für folgende Versionen geeignet:

  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Standard Edition for Small Business
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 Web
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2008 Analysis Services
  • Microsoft SQL Server 2008 Reporting Services

 

Die Release Notes finden Sie hier:
http://social.technet.microsoft.com/wiki/contents/articles/microsoft-sql-server-2008-sp2-release-notes.aspx

  • Share/Bookmark

Häufige SharePoint 2010 Fehler

Sandra Erb

Dieser Beitrag macht den Anfang einer kleinen Serie, in welcher die häufigsten Fehler- und Warnmeldungen thematisiert werden, welche sowohl nach einer Neuinstallation, als auch einer Migration von SharePoint 2007 auf SharePoint 2010 auftreten können.
Alle hier beschriebenen Fehler werden im Windows Event Log protokolliert.

Den Anfang machen die Warnmeldungen mit den Event IDs 1001,1004, 1015 und die Fehlermeldung mit der Event ID 7043.

Jonathan Briggs hat in seinem Blog übrigens eine sehr ausführliche Sammlung von weiteren Fehlern, welche nach einem In Place Upgrade auftreten können.

http://wiki.softartisans.com/display/~jonathanb/2010/08/13/Adventures+upgrading+to+SharePoint+2010


Windows Installer Warnung bei Benutzerprofilimport

Bei jedem Profilimport werden vom MsiInstaller drei Warnmeldungen ins Event Log geschrieben, der Profilimport scheint allerdings ohne weitere Probleme zu funktionieren.

Event IDs: 1001, 1004, 1015

Log Name:          Application
Source:               MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1001
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Detection of product ‘{90140000-104C-0000-1000-0000000FF1CE}’, feature ‘PeopleILM’ failed during request for component ‘{9AE4D8E0-D3F6-47A8-8FAE-38496FE32FF5}’

Log Name:         Application
Source:              MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1004
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Detection of product ‘{90140000-104C-0000-1000-0000000FF1CE}’, feature ‘PeopleILM’, component ‘{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}’ failed.  The resource ‘C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe’ does not exist.

Log Name:         Application
Source:              MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1015
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Failed to connect to server. Error: 0×80070005

Ursache

Die WMI Aufrufe werden unter dem Network Service Account ausgeführt, welcher keine Berechtigungen auf das Verzeichnis hat, in welchem sich die Microsoft.ResourceManagement.Service.exe befindet.

Lösung

Erteilen Sie dem Network Service Read & Execute Rechte auf das Verzeichnis C:\Program Files\Microsoft Office Services\14.0\. Alternativ können Sie dem Network Service auch explizit Read & Execute Rechte auf den beiden Verzeichnissen C:\Program Files\Microsoft Office Servers\14.0\Service und C:\Program Files\Microsoft Office Servers\14.0\SQL geben.

“Load control template file /_controltemplates/TaxonomyPicker.ascx failed”

Spätestens nach jedem IIS Reset wird ein Fehler im Windows Event Log ausgegeben, welcher besagt, dass die Datei “TaxonomyPicker.ascx” nicht geladen werden konnte.

Event ID: 7043

Log Name:         Application
Source:              Microsoft-SharePoint Products-SharePoint Foundation
Date:                  08.10.2010 11:02:52
Event ID:           7043
Task Category: Web Controls
Level:                 Error
Keywords:
User:                  <SharePoint Systemaccount>
Computer:          <SharePoint Server>
Description:
Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

Ursache

Dieser Fehler scheint eine Altlast in SharePoint zu sein, da die Datei “TaxonomyPicker.ascx” in SharePoint 2010 eigentlich nicht mehr im Gebrauch ist und durch die Datei “TaxonomyTreePicker.ascx” ersetzt wurde.

Lösung

Öffnen Sie das Verzeichnis C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES und benennen Sie die Datei “TaxonomyPicker.ascx” um, z.B. in “TaxonomyPicker.ascx_alt”.
Durch das Umbenennen der Datei wird verhindert, dass bei jedem neu übersetzen des Application Pools versucht wird die Datei zu laden.

  • Share/Bookmark

Backup Strategie und Transaction Log

Daniel Snellen

Bereits bei der Erstellung eines DWH sollte man sich auch Gedanken über die richtige Backup Strategie machen, da diese sonst auch schnell vergessen werden kann.

Ein falsches bzw. nicht konfiguriertes Backup kann dazu führen, dass das Transaction Log die Festplatte vollständig  beschreibt und die betroffene Datenbank nicht mehr verfügbar ist. 
Aus diesem Grund werde ich hier den Zusammenhang zwischen den Transaction Log und dem Recovery Model der Datenbank beschreiben.

Funktion des Transaktion Log

Das Transaktion Log dient zur Ausfallsicherheit. Abhängig vom Recovery Model verhält sich das Transaction Log unterschiedlich.
Zuerst werde ich die allgemeine Funktion des Transaktion Log beschreiben, später im Abschnitt Recovery Model werde ich dann auf die Besonderheiten eingehen.

Das Transaction Log tritt nur bei Schreibvorgängen in Aktion, z.B. insert, update usw.

Nehmen wir eine Insert Transaktion.
Diese Transaktion wird vom SQL Server angenommen. Bevor er diese in die Datenbank übernimmt, wird sie in den Arbeitsspeicher (RAM) und in das Transaction Log geschrieben.
Dieser Vorgang geschieht gleichzeitig und hat das Ziel die Wartezeit für den Benutzer/Prozess zu reduzieren.

Sollte nun z.B. ein Stromausfall eintreten, bevor die Transaktion in die Datenbank übernommen wurde, wäre der Inhalt im RAM verloren und die Datenbank inkonsistent.

Das Transaction Log stellt in diesem Fall die Ausfallsicherheit für den Arbeitsspeicher da.
Solange eine Transaction nicht in die Datenbank übernommen wurde, ist diese im Log auch noch als “aktiv” gekennzeichnet.
Sollte z.B. nach dem Stromausfall der Server wieder starten, erkennt der SQL Server, dass es noch nicht abgeschlossene Transaktionen im Log gibt und überführt diese zuerst in die Datenbank bevor diese wieder erreichbar ist.

Im Normalbetrieb werden die im Arbeitsspeicher abgelegten Transaktionen sobald wie möglich in die Datenbank übernommen; je nach Auslastung des SQL Servers kann es jedoch auch einige Zeit dauern.
Eine genaue Zeitangabe kann jedoch nicht gemacht werden.

Sobald eine Transaktion in die Datenbank übernommen wurde, wird diese aus dem Arbeitsspeicher gelöscht und im Transaction Log als “übernommen” markiert.

wird der SQL Server geplant beendet, so werden zunächst alle Transaktionen in die Datenbank übernommen und anschließend der Dienst beendet.

Wie nun mit den “fertigen” Transaktionen im Log weiter verfahren wird, das ist abhängig vom Recovery Model.

Recovery Model

Der MS SQL Server kennt drei Recovery Modele Simple, Full und Bulk-logged standardmäßig ist bei allen neuen Datenbanken Full eingestellt. Diese Einstellung für neue Datenbaken kann angepasst werden indem das Recovery Model der model-Datenbank geändert wird.
Diese Datenbank dient als Vorlage für alle neuen Datenbanken.

Die Einstellung des Recovery Model kann jederzeit auch im laufenden Betrieb geändert werden, beachten Sie jedoch, dass diese Änderung auch Auswirkung auf Ihre Backup Strategie hat und pro Datenbank eingestellt wird.

image

Simple

Diese Model ist, wie der Name schon sagt, das einfachste. Sobald eine Transaktion in die Datenbank übernommen und im Log quittiert wurde, wird diese auch im Log gelöscht.
Das bedeutet auch, dass das Log nur einen geringen Speicherplatz Festplatten benötigt.

Wenn für eine Datenbank gar kein Backup eingerichtet werden soll, muss für diese Datenbank das Recovery Model Simple ausgewählt werden, weil ansonsten das Transaction Log die Festplatte vollschreibt und der SQL Dienst gestoppt wird.

Full

Im Gegensatz zu “Simple” werden die Transaktionen nach erfolgreicher Übernahme in die Datenbank nicht gelöscht, sondern nur quittiert.
Das Transaction Log wird nur durch ein Transaction Log Backup gelöscht.

D.h., in diesem Model sollte immer ein Datenbank- und Transaction Log Backup durchgeführt werden, damit die Festplatten nicht vollgeschrieben werden.

Dieses Model hat einen großen Vorteil: Es kann zur minutengenauen Wiederherstellung der Datenbank z.B. bei einem Festplattenausfall, Fehlfunktion sowie Falscheingabe genutzt werden.
Hierfür ist jedoch notwendig, dass die Transaction Logs häufig gesichert werden. Man kann sagen, je geringer der Datenverlust sein darf, desto häufiger muss das Transaction Log gesichert werden. Um die Wiederherstellungszeit gering zu halten, sollte jedoch mindestens einmal Täglich eine Datenbanksicherung durchgeführt werden.

Bulk-logged

Das “Bulk-logged” Model ist fast identisch mit “Full”. Es unterscheidete sich nur insofern, dass Bulk Insert nur minimal protokoliert werden, so dass diese nicht einzeln wieder hergestellt werden können.

Backup Strategie

Für die richtige Backup Strategie gibt es leider keine “Out of the Box” Lösung, weil jede Datenbank andere Anforderungen hat.
Auch kein Backup zumachen kann eine Strategie sein.

Wichtig ist nur, dass das Recovery Model entsprechend an die Strategie angepasst wird.

  • Share/Bookmark

Do you trust your Data Mining results? – Part 2/3

Hilmar Buchta

SQL Server 2005 | SQL Server 2008 | SQL Server 2008 R2

While the first part of this post was more about the idea and interpreting the results of the test, this part shows how to implement the Monte Carlo test.

First, we need a table with the predicted data mining probabilities. This is the output of the PredictProbability function from your mining result query. I’m using the same source data as in my previous post here. If you like you can easily create your own table and populate it with random probability values in order to test the code for the simulation below:

CREATE TABLE [dbo].[Mining_Result](
    [CaseKey] [int] NOT NULL,
    [PredictScore] [float] NULL
) ON [PRIMARY]

declare @i int=0

    while (@i<10000) begin

        insert into Mining_Result(CaseKey, PredictScore)
        values(@i, convert(float,CAST(CAST(newid() AS binary(4)) AS int))/2147483648.0/2+.5)

        set @i=@i+1

end

Don’t be confused by the convert(…cast…cast newid()…) expression. This is just my approach to calculate a random number within an SQL select statement.

Next we need a table for storing our Mining results:

CREATE TABLE [dbo].[Mining_Histogram](
    [NumCases] [int] NOT NULL,
    [Count] [int] NULL,
    [Perc] [float] NULL,
    [RunningPerc] [float] NULL,
CONSTRAINT [PK_DM_Histogram] PRIMARY KEY CLUSTERED
(
    [NumCases] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

 

Then this is how we’re doing our Monte Carlo test:

truncate table Mining_Histogram;

declare @numtrials int = 10000;
declare @cnt int;
declare @lp int;

set @lp=0;

– perform a monte carlo test:

while (@lp<@numtrials) begin

    select @cnt=COUNT(*) from Mining_Result where PredictScore >
        convert(float,CAST(CAST(newid() AS binary(4)) AS int))/2147483648.0/2+.5        
    if exists(select NumCases from Mining_Histogram Where NumCases=@cnt)    
            update Mining_Histogram set [Count]=[Count]+1 Where NumCases=@cnt
        else
            insert into Mining_Histogram(NumCases,[Count]) values (@cnt, 1)
    set @lp=@lp+1;   

end

I’m using the same trick for the random numbers as shown above. In this example, we’re doing 10,000 iterations. For each iterations we compute the number of cases for which the Predicted Score is higher than a random number. For example, if for a certain case the predict score is 0.8 it is more likely that a random number between 0.0 and 1.0 is below the score than for a prediction score of 0.1.

Next, we’re filling the gaps in our histogram table with zeros to make the histogram look nicer:

declare @min int;
declare @max int;
select @min=MIN(NumCases), @max=MAX(NumCases) from Mining_Histogram

set @lp=@min;
while (@lp<@max) begin
    if not exists(select NumCases From Mining_Histogram Where NumCases=@lp)
        insert into Mining_Histogram(NumCases,[Count]) values (@lp, 0);
    set @lp=@lp+1
end

Finally we’re computing the row probability and the running total using this T-SQL:

declare @maxcount float;
select @maxcount=SUM([Count]) from Mining_Histogram;
update Mining_Histogram Set Perc=[Count]/@maxcount;

declare @CaseIdx int
declare @perc float
declare @RunningTotal float =0

DECLARE rt_cursor CURSOR FOR select NumCases, Perc From Mining_Histogram
OPEN rt_cursor

FETCH NEXT FROM rt_cursor INTO @CaseIdx, @perc

WHILE @@FETCH_STATUS = 0
BEGIN
  SET @RunningTotal = @RunningTotal + @perc
  update Mining_Histogram set RunningPerc=@RunningTotal Where NumCases=@CaseIdx
  FETCH NEXT FROM rt_cursor INTO @CaseIdx, @perc
END

CLOSE rt_cursor
DEALLOCATE rt_cursor

 

After running the simulation this is how the plots of the result look like (using my own values). The first plot shows the value of the field NumCases on the x-axis and the value of the field perc on the y-axis. The second plot has the same x-axis but shows the RunningPerc field on the y-axis:

image

 image

These two plots look very much the same as the plots from my last post (although I used C# code there to generate the histogram data).

If you used the randomly generated scores from above for testing, you will notice the peak being around 5000 cases (instead of 2800 cases in my example).

And if you like a smoother version of the density function  (as all the teeth and bumps mainly result from Monte Carlo approach), you could use this SQL query to compute a moving average:

declare @minrange int=0
declare @windowsize int = 50

select @minrange=Min(NumCases) from Mining_Histogram

SELECT     H.NumCases, AVG(H1.[Count]) [Count], AVG(H1.Perc) Perc
FROM         Mining_Histogram H
left join Mining_Histogram H1 on H1.NumCases between H.NumCases-@windowsize and H.NumCases

where H.NumCases>@minrange+@windowsize

group by H.NumCases

image

In order to do the histogram computation automatically with prediction query I recommend putting the code in an SSIS script component. I would also use another type of random number generator. This also allows you to set the seed for the random number generator. For my implementation I used an asynchronous script component that first loads all cases into memory (ArrayList collection), then performs the Monte Carlo test on the in-memory data and then writes the results back to the output buffer. This allows you do work with more scenarios and to log the progress during the loading and testing phase of the component.

I’m planning to write a Books Online Community Technical article on this topic. This article will be more detailed regarding the implementation. I will post a link to this article in my blog then.

  • Share/Bookmark

  • Kategorien

  • Copyright © ORAYLIS Blog. All rights reserved.