Archiv der Kategorie: Administration

T-SQL Abfrage für Tags

Gerade musste ich eine etwas schwierigere Auswertung machen. Die Aufgabenstellung dazu war:

“Ermittle alle Kunden, die weder der Branche Handel noch Verbraucher zugeordnet sind.”

Nun muss man wissen, dass wir die Branchen an einem Kunden quasi wie Tags haften. Im ERP sieht das so aus:

image

Dementsprechend gibt es zw. der Tabelle Kunde und Branche eine n:m Beziehung. Ein Kunde kann keinen Tag, nur einen oder mehrere haben. Ein Tag kann wiederum keinem Kunden, genau einem oder mehreren zugeordnet sein. Gemäß der Normalisierungsregeln für relationale Datenbanken ist die Tabelle Branchen so aufgebaut, dass z.B. für das oben genannte Beispiel 4 Einträge zu dem Kunden mit der ID 7001 drin stehen. Pro Tag jeweils einen Eintrag.

Das schwierige war nun, dass ich den kompletten Kundenstamm durchlaufen und für jeden gefundenen Kunden eine Unterabfrage feuern musste, die prüft, ob in irgendeinem der zugeordneten Tags der Begriff Handel oder Verbraucher vorkommt. Im Programmcode wäre das eine klassische For Each Schleife, welche im inneren nochmal eine For Each Schleife enthält (Anmerkung: Wenn man sich mit LINQ auskennt, geht es auch einfacherSmiley).

Wie macht man das nun mit T-SQL am einfachsten, wenn man zu faul ist zum Programmieren? Nachdem ich mich mit dem Wissensvermittler meines Vertrauens (Google) beraten habe, war die eleganteste und einfachste Lösung das Verwenden des Befehls

For XML Path(“)

Ein konkretes Beispiel findet ihr hier :

SELECT p1.CategoryId,
     
( SELECT ProductName + ‚,‘
          FROM Northwind.dbo.Products p2
         WHERE p2.CategoryId = p1.CategoryId
         ORDER BY ProductName
           FOR XML PATH(“) ) AS Products

  FROM Northwind.dbo.Products p1
GROUP BY CategoryId ;

In der erzeugten Spalte steht dann der XML String. Bei uns sah das so aus:

<Beschreibung>Maschinenbau </Beschreibung><Beschreibung>Anlagenbau/ Apparatebau</Beschreibung>

Nun konnte ich mit LIKE prüfen, ob in diesem z.B. Handel oder Verbraucher steht.

SQL Datenbank sichern–richtigen Haken setzen!

Wer eine SQL DB über Task – Sichern sich z.B. als Quelle für eine Test-DB sichert, sollte den Haken “Kopiesicherungen” setzen. Warum?

>>Eine Kopiesicherung ist eine SQL Server-Datensicherung, die unabhängig von der Sequenz von herkömmlichen SQL Server-Sicherungen erstellt wird. Normalerweise wird beim Erstellen einer Sicherung die Datenbank geändert, und außerdem beeinflusst dies die Art und Weise, wie spätere Sicherungen wiederhergestellt werden. Manchmal kann es sich jedoch als nützlich erweisen, eine Datensicherung für einen bestimmten Zweck vorzunehmen, ohne die allgemeinen Sicherungs- und Wiederherstellungsprozeduren für die Datenbank zu beeinflussen. Zu diesem Zweck sind in SQL Server 2005 Kopiesicherungen möglich.<<

>>Nach einer Kopiesicherung wird das Transaktionsprotokoll nie abgeschnitten. Kopiesicherungen werden in der is_copy_only-Spalte der backupset-Tabelle aufgezeichnet.<<

Quelle

SQL Datenbank kopieren

Hier eine Anleitung in Form von Screenshots, wie man auf einem MS SQL Server 2008 R2 eine Datenbank kopiert. Ab welcher Version es diese Funktion direkt integriert gibt, weiß ich nicht. Falls ihr die Funktion also nicht finden solltet, müsst ihr den Umweg über Sichern und Wiederherstellen (Anbinden) gehen. Beachtet dazu auch den nachfolgenden Blogeintrag!

Im Kontextmenü auf einer Datenbank auf Task und dann Datenbank kopieren klicken. Danach dieser Anleitung folgen.

image

image

image

Achtung: Hier habe ich die Kopie auf den gleichen Server gemacht. Normalerweise macht man sich eine Kopie auf den Testserver. Wichtig wäre in diesem Fall, dass der Quellserver Zugriff auf den Zielserver hat!

image

Da man normalerweise die Live-DB kopieren will, sollte man zu Methode zwei greifen Zwinkerndes Smiley

image

image

Da ich die Ziel DB schon gelöscht hatte, verwende ich Option 1. Normalerweise benötigt man Option 2.

Danach 2x auf Weiter klicken. Achtet im letzten Dialogfenster auf folgendes:

image

Das ist das Konto mit dem auf den Zielserver zugegriffen wird.

SharePoint Testserver: Inhaltsdatenbank aktualisieren

Da man in der Regel immer einen Testserver betreibt, habe ich eine kurze Anleitung geschrieben wie man die Inhaltsdatenbank aus dem Live System in das Testsystem kopiert.

Der Ablauf ist wie folgt:

1. Löschen der bisherigen Inhaltsdatenbank auf dem Testserver über Zentraladministration –> Anwendungsverwaltung –> Inhaltsdatenbanken verwalten. Wählt rechts oben die passende Webanwendung aus. Dann klickt ihr auf die Datenbank. Hier gibt es ganz unten die Option “Inhaltsdatenbank entfernen”. Aktiviert den Haken und klickt auf Ok. Merkt euch den Namen der Datenbank, da ihr diesen in Punkt 4 noch benötigt.

2. Kopiert euch die aktuelle Datenbank vom Live Server. Am einfachsten geht das mit dem SQL Management Studio. Falls ihr euch damit nicht auskennt, dann googelt kurz. Dazu gibt es genügend Einträge. Kopiert die Sicherung auf den Testserver.

3. Beendet auf dem Testsystem im IIS-Manager den Anwendungspool, der mit der Webanwendung verbunden ist.

4. Startet den SQL Dienst auf dem Testserver neu

5. Löscht die immer noch im SQL Server vorhandene Datenbank (den Namen habt ihr euch aus 1 gemerkt) mit dem Management Studio. Aktiviert die Option “Bestehende Verbindungen schließen” im Dialog (optional).

6. Stellt die gesicherte Datenbank wieder her.

7. Startet den Anwendungspool wieder.

8. Geht in der Zentraladministration wieder unter Inhaltsdatenbanken verwalten und wechselt auf die richtige Webanwendung. Klickt auf “Inhaltsdatenbank hinzufügen” und gebt den Datenbankserver und den Datenbanknamen an.

 

Wichtig:

  • Das funktioniert natürlich nur, wenn die entsprechenden SQL Anmeldungen, die auf dem Live-System vorhanden sind, auch auf dem Testsystem sind.
  • Die zwei Server müssen auf dem gleichen Patch-Stand sein.
  • Passt bei absoluten Links auf, da ihr sonst wieder im Live-System landet. Immer relative Links nutzen. Am besten stellt ihr das Farbschema auf dem Dev um, dann merkt ihr sofort, wenn ihr plötzlich die Plattform wechselt.

Typische SharePoint Probleme

Im Rahmen meines Besuchs des Shared Solutions Day haben sich einmal mehr die typischen Schwierigkeiten, die ich auch in früheren Gesprächen auf UserGroups und Konferenzen identifizieren konnte, bestätigt.

Hier die meiner Meinung nach verbreitetsten Probleme:

  • Die Anwender nehmen das neue System nicht an
  • Daraus resultiert auch die Problematik, dass die Systemlandschaft trotz teilweise erheblichen Aufwands und erheblicher Kosten brach liegt… Bis das System eingestampft wird
  • Ein anderer Grund ist sogar in der IT selbst zu finden: Es bleibt bei wenigen Spielereien wie leichtes Anpassen einer Liste und das Erstellen einer Dokumentenbibliothek. Danach wird das System links liegen gelassen.
  • Kein Feature wie es in SharePoint mitgeliefert wird, kann eigentlich genau so out of the box verwendet werden
  • Da jedes Unternehmen typische Geschäftsprozesse wie ‘Besprechung  vereinbaren’ immer in irgendeiner Form um eigene, unternehmensspezifische Modalitäten erweitert hat, lassen sich die vermeintlich einfachen Implementierung dann doch nicht so einfach umsetzen wie geplant. Das sogenannte Eichhörnchen… Demzufolge hat man die Wahl einen größeren Aufwand (meist Programmierung) zu betreiben oder sich mit Einschränkungen abzufinden. Beides ist in der Regel nicht akzeptabel und hinterlässt einen bitteren Beigeschmack, der den anfänglichen Optimismus stark reduziert.
  • Die eigentlich wichtigen Features, um Geschäftsprozesse dann wirklich vollständig (und nicht nur isolierte Teilprozesse) und gewinnbringend umsetzen zu können, stecken in der kostenpflichten Version. Über diesen Tellerrand wollen und können aber gerade kleine und mittelständische Unternehmen nicht hinausschauen, v.a. nicht, wenn man sich gerade erst mit SharePoint auseinandersetzt.

Im folgenden will ich ein paar Lösungsansätze vorschlagen:

Der eigentliche Knackpunkt, bevor man überhaupt zu SharePoint greift, ist, dass man sich klar macht, dass man wie bei jedem anderen System alleine durch die Anschaffung und Einarbeitung Zeit- und Kostenaufwand hat. Lediglich weil die SharePoint Foundation bzw. die Windows SharePoint Services kostenfrei erhältlich sind und weil es gerade in aller Munde ist, heißt dies gewiss nicht, dass nicht wie bei jeder anderen Produkteinführung auch eine entsprechende Planung vorausgehen muss.

Drei wichtige Schritte gehören in jedem Fall zu dieser Planung:

Schritt 1: Holen Sie sich von Anfang an die Fachabteilungen ins Boot. Greifen Sie sich hier v.a. die Abteilungsleiter und IT-affine Mitarbeiter heraus. In der Regel sind diese Personen entscheidend allgemeinen Annahme des neuen Systems.

Schritt 2: Identifizieren Sie gemeinsam einen ausgewählten Satz an einfachen Geschäftsprozessen. In der Regel gibt es fast immer solche, deren Ablauf nicht wirklich störend aber dafür hinderlich sind. Meistens finden sie solche Prozesse, indem sie prüfen, was schon lange auf einer ToDo-Liste steht und immer wieder wegen niedriger Priorität verschoben wird (sogenannte nice-to-have Feature). Idealerweise sollte es auch ein Prozess sein, der viele Mitarbeiter betrifft. Ein Beispiel könnte das Ausdrucken und das manuelle Ausfüllen von Anträgen (z.B. Urlaub) sein, was jeder Verkäufer 1-2 Mal pro Monat machen muss.

Schritt 3: Holen Sie sich einen Mann vom Fach dazu, der längere praktische Erfahrung in diesem Bereich hat. Es reicht keinesfalls aus auf Vorträge zu gehen oder sich durch Online Material zu arbeiten. Vergessen Sie ähnliche Beispiele von Konferenzen und UserGroups, da wie schon erwähnt der Teufel im Detail steckt. In der Regel reicht es völlig aus, wenn man sich einen Tag mit dem SharePoint Consultant zusammensetzt. Stellen Sie klar, dass sie für die Lösungen nur auf die mitgelieferten Hilfsmittel in SharePoint zurückgreifen möchten (Anmerkung: Hin und wieder können vor allem auch kostenfreie Lösungen im Netz ganz hilfreich sein!). Programmieren sollte in diesem frühen Stadium kein Thema sein. Wichtig: Es geht in diesem Gespräch noch nicht um einen detaillierten Plan zur Umsetzung. Lediglich die Machbarkeit und den benötigen Zeitraum gilt es zu evaluieren. Bedenken Sie: Die Kosten für diesen einen Tag sind in jedem Fall geringer als SharePoint aus dem Gedanken heraus aufzusetzen, dass man ja einfach mal das Ganze testen und ein wenig herumspielen will.

Wenn sich nach diesen drei Schritten herausstellt, dass Ihre Anliegen durchaus machbar sind, dann können Sie loslegen. Andernfalls werden Sie mit hoher Wahrscheinlichkeit keinen großen Erfolg bei der SharePoint Integration haben. Halten Sie sich bei der Realisierung an folgende zwei wichtige Regeln:

  • Führen sie immer eine Änderung nach der anderen durch und fangen sie mit den kleinsten davon an
  • Setzen Sie Lösungen für die alltäglichen Geschäftsprozesse um, die das Gros der Mitarbeiter betrifft

Wohlgemerkt halte ich diese zwei Regeln nur für sinnvoll bis eine allgemeine Akzeptanz erreicht bzw. SharePoint eingeführt wurde! Um Ihnen ein paar Beispiele zu nennen, was wir uns dafür herausgegriffen haben:

  • Wir haben die Möglichkeit geschaffen, dass zentral auf der Startseite jeder Mitarbeiter für den heutigen und morgigen Tag einsehen kann, wer an- und wer abwesend ist. Dazu gehört auch, wenn jemand Urlaub hat oder lediglich für ein paar Stunden nicht verfügbar ist.
  • Wichtige Firmennachrichten werden ebenfalls auf der Startseite veröffentlicht. Idealerweise kommen hier mindestens 1-2 neue pro Woche hinzu. Meistens werden die Neuigkeiten durch die Abteilungsleiter eingepflegt. In einem Handelshaus könnten das auch Bekanntmachungen bzgl. der Preisanpassungen sein.
  • Für uns im Handel war ein zentrales Werkzeug der Tourenplan unserer LKWs. Ein Gespräch (vgl. Schritt 1 weiter oben) ergab, dass dieser von allen Verkäufern täglich eingesehen wurde.
  • Tipp-Spiel: Ja, auch solche kleine Dinge können sehr zuträglich sein. Bisher konnte ich für jede EM und WM ein entsprechendes Feature online finden, das ich kostenlos bei uns einbinden konnte. Die Beteiligung an den Tippsielen ist seit Jahren extrem hoch!

Diese 4 Features bewirkten, dass jeder Mitarbeiter mindestens 1x täglich – nämlich morgens – zum Intranet navigierte, um sich einen Überblick für den Tag zu verschaffen. Mit der erwähnten Option die Infos auch für den morgigen Tag einsehen zu können, wurde nach kurzer Zeit dann jeden Abend nochmal hineingeschaut. Nach relativ kurzer Zeit hatten wir so eine vollständige Akzeptanz innerhalb der Belegschaft erreicht. Darauf ließen sich dann weitere Projekte aufsetzen. Hier kann ich vor allem zwei Kernpunkte identifizieren:

  • Dokumentenmanagement, um dem Chaos in der Dateiablage und den öffentlichen Ordnern Herr zu werden
  • Projektmanagement, da es immer und überall Projekte gibt und das Thema an sich seit jeher schwierig und komplex ist

Meines Erachtens nach gibt es jetzt zwei Möglichkeiten wie sie fortfahren können. Das ist vor allem von Ihren Ressourcen und Ihrer IT abhängig. Entweder Sie setzen eines der Themen gleich für Ihren Betrieb um oder – und das ist der bessere Weg – Sie lassen die IT fachinterne Geschäftsprozesse für sich umsetzen, quasi als Prototyp. In der Regel werden Sie hier schon auf eines der oben genannten Themen stoßen. Bei uns war es eine Dokumentationsseite mit allen IT Dokus und eine Inventarliste unserer Soft- und Hardware. Mit diesen Erfahrungen gingen wir die dann die oben genannten Punkte an.

Speziell auf Rückmeldungen zu diesem Artikel würde ich mich besonders freuen. Ich möchte nochmal darauf hinweisen, dass die oben genannten Punkte meine subjektive Wahrnehmung und Meinung wiedergeben. Vergessen Sie auch nicht, dass sich diese Ergebnisse im Rahmen meiner Tätigkeit in einem mittelständischen Handelsbetrieb aus der Edelstahlbranche ergeben haben.

XML-Datentyp im SQL Server

In meinem Artikel zu DTOs beschrieben habe, lassen sich Datenobjekte sehr leicht als XML serialisieren. Ich habe das Konzept aufgegriffen und zur Datenhaltung von Konfigurationen verwendet. Die XML Daten speichere ich in einer dedizierten DB-Tabelle (die Tabellenstruktur hierfür werde ich in einem späteren Blogeintrag veröffentlichen). Jetzt musste ich mir überlegen, welchen Datentyp ich für die entsprechende Spalte mit den XML Werten verwende: Nehme ich varchar(max) oder XML.

XML als vollwertigen Datentyp gibt es bereits seit SQL Server 2005. Da wir SQL Server 2008 R2 einsetzen, wäre es also durchaus zu erwägen. Um eine sondierte Entscheidung treffen zu können, habe ich mir ein SQL Server 2008 Buch (nicht R2!) zur Hand genommen. Zunächst einmal einige Vorteile:

  • Constraints &  Indizes können darauf erstellt werden
  • Setzen eines Defaultwertes ist möglich
  • Validierung gegen ein im SQL Server hinterlegtes Schema
  • Ausführung von in SQL-Befehlen eingebettetes XQuery

Hört sich zunächst einmal ganz gut an. Nun aber ein gravierender Nachteil, der zumindest für den SQL Server 2008 gilt (bzgl. R2 kann ich keine Aussage machen, allerdings glaube ich nicht, dass sich etwas geändert hat):

Wegen der binären Speicherung können XML Dokumente nicht zu 100% identisch erhalten werden, sodass etwa Leerzeichen entfernt und die Reihenfolge der Attribute verändert werden.

Nun ja, bei einer Config-Tabelle ist dies vielleicht nicht wesentlich von Bedeutung, aber wenn exakte Kopien eines XML Dokumentes z.B. aus rechtlichen Gründen benötigt werden, dann wäre dies keine Option. Diese Information, auch wenn Sie vielleicht zunächst einmal nicht relevant für meine technischen Anforderungen ist, stieß mir doch ein wenig auf. Hinzu kommt, dass die Vorteile für mich keine zwingende Notwendigkeit sind.

To make a long story short: Ich entschied mich beim Persistieren von Konfigurationsdaten, die als XML vorliegen, für den Datentyp varchar(max).

Classless Inter-Domain Routing – Teil 2

Nachdem ich im ersten Teil auf die Theorie eingegangen bin, kommen wir jetzt auf die Konzeption und Planung zu sprechen: Der erste Schritt vor der Planung ist zunächst einmal ein Proof of Concept, um die Idee des CIDR zu validieren.

Deshalb setzten wir zunächst einmal eine kleine Testumgebung samt einem Domain Controller auf. Bei uns waren es zwei Server, wobei einer die Rolle des DC innehatte, sowie 3 Clients, davon 2 virtuell. Die Clients erhielten per DHCP ihre IP vom DC, der zweite Server hatte eine feste Adresse. Außerdem lief auf dem zweiten Server eine kleine Serversoftware, auf welche von den Clients zugriffen wurde (beispielsweise könnte man hier einen FTP Server aufsetzen). Das Einrichten der Testumgebung ist der anspruchsvollste Teil. Danach ändert man lediglich an den zwei Servern manuell die Subnetzmaske. Darüber hinaus muss man auf dem DC noch prüfen, ob dieser per DHCP auch die richtige Subnetzmaske verteilt. Im Anschluss funktionierte alles weiterhin wie gewohnt. Demzufolge hatten wir im kleinen Rahmen sichergestellt, dass der Gedanke zur Vergrößerung unseres Netzes durchaus funktionieren kann.

Um zumindest ein gewisses Maß an Sicherheit über das geplante Vorhaben zu bekommen, recherchierten wir im Internet noch über etwaige bekannte Probleme. Da es hier stark davon abhängt, wie die eigene Infrastruktur aussieht, will ich nicht näher auf die Funde eingehen. Lediglich folgendes sei angemerkt: Einige alte Protokolle können hier durchaus Probleme haben. Außerdem stießen wir auf Einzelfälle, die über Schwierigkeiten beim VPN Zugriff berichteten. Diesen Punkt schrieben wir auf unsere Liste.

Abgesichert durch unseren Test und die Recherche, gingen wir zur detaillierten Planung über. Wir begannen mit einer Bestandsaufnahme, d.h. welche Geräte hängen alle am Netzwerk, wie sind sie angeschlossen und – was oft vergessen wird – funktionieren diese überhaupt. In der Regel ist es so, dass der verfügbare Adressbereich des eigenen Netzes (bei uns 192.168.115.0 bis 192.168.115.256) in zwei Segmente aufgeteilt wird: Den DHCP Bereich, aus dem der Domain Controller IPs an die Clients verteilt, und den festen Adressbereich, der vorwiegend für Server, aber auch diverse Peripherie verwendet wird. Während das DHCP Segment keinerlei Vorüberprüfung bedarf, sieht die Sache bei den festen IPs anders aus. Wir nahmen unseren bereits existierenden Netzwerkplan (den es hoffentlich in jeder Firma gibt), auf dem neben den Servern auch alle sonstigen, ans Netzwerk angeschlossenen Geräte vermerkt sind, darunter Drucker, Faxe, Scanner, Multifunktionsgeräte, Audio Codes, Webcams, Printserver und viele mehr (z.B. die Alarmanlage!). Bei der Überprüfung kam heraus, dass der Plan lediglich zwei falsche Geräte auswies, die drei Tage vorher gegen neuere getauscht wurden. Ich selbst würde dies als durchaus guten Wert bezeichnen, wenn man bedenkt wie viele Geräte wir haben und wie oft welche getauscht werden. Danach nutzten wir einen klassischen Netzwerkscanner, um erstens zu prüfen, ob wir irgendwelche Peripherie aus dunklen Kämmerchen vergessen hatten, und zweitens, um auch sicherzustellen, dass die Hardware überhaupt funktionierte. Das Ergebnis des Ping-Tests haben wir uns für einen späteren Vergleich abgespeichert. Zu guter Letzt prüften wir noch, ob wir auf alle gefundenen Geräte Zugriff hatten (z.B. über das Webinterface eines Audio Codes) und ob es dort auch möglich war die Netzwerkeinstellung zu ändern. Dabei stellten wir fest, dass wir von zwei Druckern keine Zugangsdaten hatten. Diese waren durch das Handbuch schnell gefunden.

Hier nochmal zusammengefasst, welche Punkte wir bereits abgehandelt haben:

1. Proof of Concept

2. Recherche bzgl. bekannter Probleme

3. Bestandsaufnahme / Analyse der Ausgangssituation

In Teil 3 gehen wir dann auf die konkrete Umstellung ein.

%d Bloggern gefällt das: