[ Teil 1 | Teil 2 | Teil 3 ]
In Teil 1 und Teil 2 dieser Serie habe ich ParamParser vorgestellt:ein PowerShell-Modul, das beim Analysieren von Parameterinformationen hilft – einschließlich Standardwerten – von gespeicherten Prozeduren und benutzerdefinierten Funktionen, da SQL Server dies nicht für uns tun wird.
In den ersten Iterationen des Codes hatte ich einfach eine .ps1-Datei, mit der Sie einen oder mehrere Modulkörper in eine fest codierte $procedure einfügen konnten Variable. In diesen frühen Versionen hat viel gefehlt, aber wir haben uns bisher mit mehreren Dingen beschäftigt:
- Es ist jetzt ein richtiges Modul – Sie können
Import-Module .\ParamParser.psm1ausführen und rufen Sie dannGet-ParsedParamsauf während einer Sitzung funktionieren (zusätzlich zu den anderen Vorteilen, die Sie aus einem Modul ziehen). Das war keine triviale Umstellung – noch einmal großes Lob an Will White. - Unterstützung benutzerdefinierter Funktionen – Ich habe in Teil 2 erklärt, dass Funktionsnamen schwerer zu parsen sind als Prozedurnamen; der Code behandelt dies jetzt ordnungsgemäß.
- Automatisierung von ScriptDom.dll – wir dürfen diese Schlüsseldatei nicht weitergeben, und weil Sie Probleme bekommen können, wenn Sie sie nicht haben (oder eine veraltete Version haben), hat Will
init.ps1erstellt , wodurch automatisch die neueste Version (derzeit 150.4573.2) heruntergeladen und extrahiert und im selben Ordner wie die anderen Dateien abgelegt wird. - Zusätzliche Quellen – Sie können immer noch einen rohen Skriptblock übergeben, wenn Sie möchten, aber jetzt können Sie auch mehrere Instanzen und Datenbanken als Quellen verwenden, auf eine oder mehrere Dateien direkt verweisen oder alle
.sqleinlesen Dateien aus einem oder mehreren Verzeichnissen. Ich werde unten eine Beispielsyntax zeigen. - Ausgabe gibt Quelle an – Da Sie mehrere Dateien oder Datenbanken in einem Aufruf verarbeiten können und möglicherweise mehrere Objekte mit demselben Namen haben, hilft das Einbeziehen der Quelle bei der Unterscheidung. Ich kann nicht viel tun, wenn Sie zwei Instanzen von
CREATE PROCEDURE dbo.blat ...haben in der gleichen Datei oder im Rohskript, und die Quelle wird nicht einmal angegeben, wenn Sie-Scriptverwenden und einen String übergeben. - Verbesserte Ausgabe – Sie können immer noch alles auf die Konsole ausgeben, aber Sie können auch
Out-GridViewverwenden um die Ergebnisse in einem Rasterformat anzuzeigen (hier ist ein langweiliges Beispiel von AdventureWorks2019) oder die Parameterinformationen in einer Datenbank zur Verwendung an anderer Stelle zu protokollieren.
Befolgen Sie zum Herunterladen und Einrichten die Anweisungen in der Readme-Datei. Nachdem Sie das Repository geklont haben, führen Sie .\init.ps1 aus und dann Import-Module .\ParamParser.psm1 . Testen Sie es mit einem einfachen Beispiel wie:
Get-ParsedParams -Script "CREATE PROCEDURE dbo.a @b int = 5 out AS PRINT 1;" -GridView
Ausgabe (zum Vergrößern anklicken):
Es gibt jedoch auch viele andere Parameterkombinationen. Der Hilfe-Header zeigt einen guten Teil der möglichen Syntax (und nochmals vielen Dank an Will für die erstaunliche Bereinigung hier):
Get-ParsedParams -?
Ergebnisse:
Get-ParsedParams [-Script]Get-ParsedParams [-File]
Get-ParsedParams [-Directory]
Get-ParsedParams [-ServerInstance]
Noch ein paar Beispiele
Um alle Objekte in c:\temp\db.sql zu analysieren :
Get-ParsedParams -File "C:\temp\db.sql" -GridView
Zum Analysieren aller .sql-Dateien in c:\temp\scripts\ (rekursiv) und h:\sql\ (auch rekursiv):
Get-ParsedParams -Directory "C:\temp\scripts\", "H:\sql\" -GridView
Um alle Objekte in msdb zu analysieren auf der lokalen benannten Instanz SQL2019 mit Windows-Authentifizierung:
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -GridView
Um alle Objekte in msdb zu analysieren , floob und AdventureWorks2019 auf der lokalen benannten Instanz SQL2019 und Sie werden zur Eingabe der Anmeldeinformationen für die SQL-Authentifizierung aufgefordert:
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb","floob","AdventureWorks" -AuthenticationMode "SQL" -GridView
Um alle Objekte in msdb zu analysieren auf der lokalen benannten Instanz SQL2019 und geben Sie die Anmeldedaten für die SQL-Authentifizierung ein:
$password = ConvertTo-SecureString -AsPlainText -Force -String "Str0ngP@ssw0rd" $credential = New-Object -TypeName "PSCredential" -ArgumentList "SQLAuthUsername", $password Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -AuthenticationMode "SQL" -SqlCredential $credential -GridView
Zum Analysieren aller .sql-Dateien in c:\temp\scripts\ (rekursiv) und fügen Sie die Ergebnisse in eine Tabelle in der lokalen benannten Instanz SQL2019 ein in einer Datenbank, Utility , wo Sie bereits dbo.ParameterSetTVP erstellt haben , dbo.LogParameters , usw., mit Windows-Authentifizierung:
Get-ParsedParams -Directory "C:\temp\scripts" -LogToDatabase -LogToDBServerInstance ".\SQL2019" -LogToDBDatabase "Utility"
Um alle Objekte in msdb zu analysieren auf der lokalen benannten Instanz SQL2019 und in das Utility schreiben Datenbank auf derselben Instanz mit denselben Anmeldedaten für die SQL-Authentifizierung:
$password = ConvertTo-SecureString -AsPlainText -Force -String "Str0ngP@ssw0rd"
$credential = New-Object -TypeName "PSCredential" -ArgumentList "SQLAuthUsername", $password
Get-ParsedParams -ServerInstance ".\SQL2019" -Database "msdb" -AuthenticationMode "SQL" -SqlCredential $credential -LogToDatabase `
-LogToDBServerInstance ".\SQL2019" -LogToDBDatabase "Utility" -LogToDBAuthenticationMode "SQL" -LogToDBSqlCredential $credential Das wird langsam chaotisch, aber hoffentlich automatisieren Sie das und müssen es nicht jedes Mal von Hand eingeben.
Nächstes Mal
Wie immer können noch weitere Verbesserungen vorgenommen werden. Ich mag die Parameternamen nicht, die ich mir ausgedacht habe, aber ich denke, es gibt wichtigere Verbesserungen, wie Fehlerbehandlung und Erweiterbarkeit, die vorgenommen werden sollten. Irgendwelche Vorschläge? Bitte lassen Sie es mich wissen oder, noch besser, leisten Sie einen Beitrag!
[ Teil 1 | Teil 2 | Teil 3 ]
