Dajmy na to, że chcesz wyświetlić informację o błędzie i zawrzeć w niej nazwę aktualnie uruchomionej funkcji. Posłuż się:
$MyInvocation.MyCommand
W przypadku Powershell 2.0 analogicznym poleceniem jest:
(Get-PSCallStack)[0].Command
Tutaj sprawa wygląda jeszcze fajniej, bo można zapytać, jaka funkcja wywołała moją funkcję używając:
(Get-PSCallStack)[1].Command
Jeśli chcesz zebraćlub zmodyfikować pewne właściwości na temat SQL serwera możesz przejrzeć rejestr. Rejestr ma trochę specyficzną budowę. Po pierwsze należy zajrzeć do klucza:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL
Znajdziesz tutaj właściwości, których nazwa jest równa nazwie instancji, a ich wartość, to nazwa klucza, którego należy poszukać aby dostać się do właściwych parametrów instancji SQL
W tak znalezionym kluczu odnajdziesz sporo informacji o konfiguracji SQL. Np.:
Istnieje też klucz:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer
Klucz był wykorzystywany w wersji 2000, obecnie zawiera wybrane informacje o instancji domyślnej.
Aby edytować rejestr z poziomu powershell zajrzyj: Powershell czytane rejestru dla SQL
(Zajrzyj też do wpisu Rejestr dla SQL)
Rejestr możesz przeglądać edytować używając standardowych komend Set-Location, New-Item, Set-ItemProperty, ale komendy te mają jedną wadę. Pracują lokalnie. Jeżeli masz zamiar pracować z rejestrem zdalnym lepiej będzie posłużyć się obiektem .NET pozwalającym na takie rzeczy. Zaczynamy od zadeklarowania zmiennych (w moim przypadku poszukam numeru portu na którym pracuje instancja SQL SQLEXPRESS):
$computer=’server001’ $instance=’SQLEXPRESS’ $reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(’LocalMachine’, $computer)W ten sposób obiekt $reg pozwala pracować z gałęzią Local_Machine na komputerze server001. Teraz poszukamy wartośi klucza:
$key=’SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL’ $subKey= $reg.OpenSubKey($key)Ten klucz zawiera informacje o tym jakie instancje są zainstalowane na serwerze oraz jakie podklucze w HKLM\Software\Microsoft\Microsoft SQL Server odpowiadają za te instancje.
Poniższe polecenie wyciąga z klucza 'SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL’ wartość właściwości o nazwie SQLEXPRESS, bo
-$subKey wskazuje obecnie na SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL
-$instance = SQLEXPRESS
$instanceRegistryKey=$subKey.GetValue($instance)
W ten sposób w $instanceRegistryKey masz wartość „MSSQL11.SQLEXPRESS”. Dzięki niej możesz odnaleźć właściwe miejsce w rejestrze do odczytania konfiguracji interesującej cię instancji.
Aby zbadać na jakim porcie działa wybrana instancja szukajmy dalej:
$key=”SOFTWARE\Microsoft\Microsoft SQL Server\$instanceRegistryKey\MSSQLSERVER\SUPERSOCKETNETLIB\TCP\IPALL” $subKey=$reg.OpenSubKey($key)Teraz $subKey wskazuje na klucz SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQLSERVER\SUPERSOCKETNETLIB\TCP\IPALL
Aby odczytać numer portu wystarczy wykonać ostatnie polecenie:
$port=$subKey.GetValue(„TcpPort”)
To działa! Jeśli chcesz wysłać pocztę z konta gmail.
$cred=Get-Credential(„Imie_Nazwisko”) Send-MailMessage -SmtpServer smtp.gmail.com -Port 587 -Credential $cred -UseSsl true -From ’Imie_Nazwisko@gmail.com’ -To ’Czyjes_Konto@gmail.com’ -Subject 'TEST’Mniej intuicyjne opcje to:
Credential może też być zapisany w zaszyfrowanym pliku i wczytany przed wysłaniem maila. A jak to zrobić? Tak:
1. Najpierw pobierz hasło:
$cred = Get-Credential -Credential „Imie_Nazwisko”2. Zapisz credential w pliku:
$cred.Password | ConvertFrom-SecureString | Set-Content c:\temp\psswd.txtplik zawiera zaszyfrowane hasło. (Szyfr nie jest wyjątkowo mocny, ale zawsze to coś).
3. Przed wysyłką maila wczytaj dane z pliku:
$password = Get-Content C:\temp\psswd.txt | ConvertTo-SecureString4. Utwórz obiekt credential:
$cred = New-object System.Management.Automation.PsCredential(„Imie_Nazwisko”,$password)W nowszych wersjach (od SQL 2005) do sprawdzenia rozmiaru bazy danych można sie posłużyć zapytaniem:
SELECT sum(size*8.0/1024) AS SizeOnDisk, sum(FILEPROPERTY(name, 'SpaceUsed’) *8.0/1024) AS SizeUsed FROM sys.database_files
Niestety takie zapytanie w SQL 2000 nie zadziała, bo tam nie istnieje widok sys.database_files. Tam należy skorzystać z tabeli systemowej sysfiles:
SELECT sum(size*8.0/1024) AS SizeOnDisk, sum(FILEPROPERTY(name, 'SpaceUsed’) *8.0/1024) AS SizeUsed FROM sysfiles
Taka tabela istnieje też w kolejnych wersjach SQL servera, więc można by powiedzieć, że to drugie zapytanie jest uniwersalne. Microsoft nie gwarantuje jednak, że w kolejnych edycjach coś się w tej tabeli znie zmieni… dlatego jeśli można lepiej używać pierwszego zapytania.
Tak:
$x=Get-WmiObject -ComputerName serwer01 -Class win32_operatingsystem
$x.OSARCHITECTURE
Jak widać sprawdzenie może sie odbyć zdalnie.
Pełny komunikat (3314):
During undoing of a logged operation in database 'MyDB’, an error occurred at log record ID (206671:82089:65). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
a poprzedni komunikat to (1203):
Process ID 123 attempted to unlock a resource it does not own: PAGE: 9:5:7933. Retry the transaction, because this error may be caused by a timing condition. If the problem persists, contact the database administrator.
Cóż robić?
1. Uruchom DBCC:
dbcc checkdb (’OperationsManagerDW’) with no_infomsgs
2. Jeśli nic nie zostanie znalezione – jesteś uratowany
3. Jeśli będzie błąd: backup i spróbuj REPAIR_REBUILD (w SINGLE_USER)
4. A jeśli i to nie pomoże to cytuję „Restore the database or file from a backup, or repair the database.”
Inne rozwiązania:
http://dba.stackexchange.com/questions/39066/process-attempted-to-unlock-a-resource-it-does-not-own
