Biznes zwraca się z pyaniem „To ile właściwie mamy dysków i o jakim rozmiarze w serwerze XXX?”. Wchodzisz na serwer i widzisz dyski C: D: E: F: G: H: I: J:….., no przecież nie będę tego liczyć na piechotę!

Zaczynamy od

Get-WmiObject win32_logicaldisk

Wynik już mamy, ale w bajtach i dla każdego dysku oddzielnie.

W takim razie najpierw przeliczmy bajty na gigabajty. W tym celu posłużymy się wyrażeniem Select tworzącym nowe, wyliczane kolumny:

Get-WmiObject win32_logicaldisk | 
Select DeviceID,@{n='SizeGB';e={$_.Size/1GB,2}},
 @{n='FreeGB';e={$_.FreeSpace/1GB}}

Czytaj dalej »

Przydatna komenda ze starego DOS-a pozwala zamapować dysk z linii komend:

net use Q: \\server001.domain.net\d$ /user:domena\username

W moim przypadku musiałem z zasobu sieciowego uruchomić program „jako administrator”. Niestety jeśli zmapowałem dysk jako normalny użytkowik, to uruchamiając cmd traciłem informację o zamapowanym dysku. Dlatego mapowanie musiałem zrobić po uruchomieniu cmd.exe.

Jeśli znasz ogólne zasady obsługi błędów w powershell, to nie odkryję tutaj dla Ciebie żadnej nowej filozofii. Jeśli jednak szukasz ogólnej informacji „jak poradzić sobie z błędem w skrypcie” to czytaj dalej.

Zaczynamy od

Import-Module sqlps

Wypróbuj działanie komend wybierających kontekst nieistniejącego serwera SQL lub nieistniejącej bazy danych:

Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction Stop;
Write-Host -foregroundcolor Yellow „Here next command”

W tym przypadku powinna się wyświetlić informacja o błędzie, ale komunikat z Write-Host nie wyświetli się. ErrorAction Stop oznacza, że po błędzie zatrzymujemy działanie skryptu. Popatrz na drugi przykład:

Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction Continue;
Write-Host -foregroundcolor Yellow „Here next command”

Teraz komunikat o błędzie też się wyświetlił, ale linijka Write-Host też się wykonała, bo ErrorAction Continue oznacza, że mimo błędu skrypt ma być kontynuowany. I trzeci przykład:

Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction SilentlyContinue;
Write-Host -foregroundcolor Yellow „Here next command”

(Chcesz wiedzieć więcej? Zobacz lekcję o parametrze ErrorAction dostępną za darmo w ramach kursu Powershell dla administratora Windows)

Czytaj dalej »

Ulubioną lekturą MSSQL DBA jest plik errorlog. Można go oczytywać w SQL Server Management Studio, z wykorzystaniem sp_readerrorlog, ale da się też z powershella.  Jak zwykle zaczynamy od stworzenia obiektu SMO odpowiadającego za naszą instancję SQL:

$server = New-Object -type Microsoft.SqlServer.Management.Smo.Server -ArgumentList localhost

Do odczytania błędów skorzystaj z:

$err = $server.ReadErrorLog()

Najważniejsze właściwościi tak uzyskanego obiektu to:

LogDate Property dateime LogDate {get;set;}

ProcessInfo Property string ProcessInfo {get;set;}

Text Property string Text {get;set;}

Czytaj dalej »

W moim przypadku błąd pojawiał się po uruchomieniu innej komendy na Fedorze. W celu rozwiązania problemu należało zainstalować glibc.i686

Zacząłem od znanej mi komendy:

yum install glibc.i686

Ale niestety – za wiele się zmieniło od czasu kiedy ostatnio się goniłem z pingwinami…. Teraz robi się to poleceniem:

dnf install glibc.i686

Jak to na Linuxie, pościągało poinstalowało i zadziałało 🙂

BTW: Co to są pingwiny? To jaskółki, które podjadały po 18-tej 🙂

W linuxie mamy jednego roota. W Windows dla odmiany mamy grupę local administrators i wystarczy dodawać do niej użytkowników i już użytkownicy ci mają podniesione uprawnienia. Kiedy w Linuxie chcesz mieć więcej administratorów i na dodatek móc ich rozliczyć za wykonywane czynności (audytować) to korzystasz z pliku /etc/sudoers.

Plik określa kto (użytkownik lub grupa) na jakim komputerze (np. localhost) może uruchamiać jakie komendy. Np. root ma zdefiniowane prawo do uruchamiania wszystkich komend z jakiegokolwiek komputera:

root     ALL=(ALL)   ALL

Załóżmy, że chcesz aby kilku wybranych użytkowników mogło pracować z uprawnieniami równymi root.

1. Załóż grupę np. admins:

groupadd admins

2. Dodaj do tej grupy użytkowników, którycm chcesz pozwolić na coś więcej

usermod -a -G admins rafal

3. Wyedytuj plik /etc/sudoers. W tym celu użyj komendy

visudo

(jest to specjalna komenda do edycji pliku sudoers zaprojektowana tak, aby przypadkiem jednocześnie dwie osoby nie modyfikowały tego pliku jednocześnie). Dodaj tam linię:

%admins     ALL=(ALL)   ALL

4. Zaloguj się na nowo na użytkownika, który ma mieć prawo do podnoszenia swoich uprawnień, tutaj użytkownik rafal, a potem wykonaj polecenie:

sudo <komenda do wykonania>

np.:

sudo dnf install glibc.i686

Prawdopodobnie po instalacji Service Pack SQL nie uruchamiał się. W error logu można znaleźć:

FileMgr::StartLogFiles: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'D:\MSSQL11.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.ldf’. Diagnose and correct the operating system error, and retry the operation.

To podobno częsty bład jeżeli domyślna lokalizacja baz systemowych została zmieniona. Zdarza się też na clustrach. Ponieważ MSSQLSystemResource jest bazą systemową tylko do odczytu i traktowaną raczej jako element instalacji niż prawdziwa baza danych można wybrać naprawę SQL z panelu sterowania lub… poszukać takiej samej bazy danych w innej instalacji. Jeśli wybierzesz nie tą wersję co należy, to bład może się zmienić na:

The resource database version is 782 and this server supports version 706. Restore the correct version or reinstall SQL Server.

Szukaj do skutku. Skopiuj plik mdf i ldf do wskazanego w pierwszym komunikacie katalogu aż w końcu się uda!