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)
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;}
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!
1. Zaloguj się na konto Sybase (w ASE 16 domyślna nazwa konta to sap)
2. Uruchom:
. ./SYBASE.sh
Spowoduje to załadowanie zmiennych środowiskowych dla tej instalacji Sybase
3. Przejdź do katalogu install (/opt/sap/ASE_16.0/install):
cd $SYBASE/$SYBASE_ASE/install
Zmienne środowiskowe zostały zdefiniowane w kroku poprzednim
4. Uruchom
showserver
Ten skrypt wyszukuje procesów z nazwą (między innymi) dataserver
5. Jeśli polecenie nie wyświetliło numeru procesu, to uruchom sybase (zakładając, że twój serwer to SAP01):
startserver -f RUN_SAP01
startserver uruchamia Sybase (czyli proces dataserver) przekazując mu parametry zawarte w pliku RUN_SAP01. Zawartość tego pliku wskazuje opcje:
-d – lokalizacja bazy danych master
-e – error log
-c – lokalizacja pliku config
-M – lokalizacja plików Memory files
-N – lokalizacja licencji
-i – lokalizacja pliku interfaces
-s – nazwa serwera
6. Aby ewentualnie zatrzymać SAP wykonaj:
isql -S SAP01 -U sa
co uruchomi połączenie do Sybase, a następnie wykonaj:
SHUTDOWN WITH NOWAIT GO
Połączenie zostanie przerwane, a serwer zostanie zatrzymany
