ING Services Polska, ING Bank Śląski oraz IBM zapraszają studentów kierunków informatycznych do uczestnictwa w prestiżowym programie Corporate Readiness Certificate (CRC) realizowanym w Gliwicach, Katowicach i Wrocławiu.

http://www.ingservicespolska.pl/pl/aktualnosci,10/841,studencie-zapisz-sie-do-programu-crc.html

http://www.ack.ue.katowice.pl/news/2215/Przystap-do-organizowanego-w-naszej-Uczelni-Programu-Corporate-Readiness-Certificate-CRC—Ucz-sie-od-specjalistow-IBM-ING-Bank-Slaski-ING-Services-Polska

W ramach programu CRC będę miał przyjemność poprowadzić wykłady poświęcone automatyzacji systemu Windows z wykorzystaniem języka skryptowego Powershell. Podczas pierwszych zajęć, które odbędą się… w Prima Aprilis opowiem o:

• tym, co to jest i jak powstał Powershell
• różnicach między językami skryptowymi znanymi ze świata Unix, a obiektowym Powershellem
• narzędziach, w których można tworzyć skrypty
• podstawowych komendach Powershell
• tworzeniu potoków
• sortowaniu, filtrowaniu, iteracji…

Skrypt poniżej: Czytaj dalej »

Jeśli podejrzewasz, że część baz danych na serwerze wydaje ci się nieużywana, to pomocne może być poniższe zapytanie. SQL po starcie, ilekroć zapytanie skorzysta z indeksów, zapisuje informację o tym fakcie w sys.dm_db_index_usage_status. Jeśli serwer pracuje już miesiąc a w wyniku widzisz NULL w polach daty ostatniego wykorzystania indeksu, to może ta baza już nie jest przez nikogo wykorzystywana… Pamiętajmy jednak, że widok ten zeruje się po restarcie serwera, więc przy podejmowaniu decyzji o usunięciu bazy, dobrze byłoby sprawdzić wykorzystanie jeszcze przez sesję profilera, a przed usunięciem na jakiś czas przełączyć bazy w tryb offline. Potraktuj to zapytanie tylko jako wstęp do badania, czy bazy są wykorzystywane.

SELECT
d.name,
MAX(user_seeks) AS MaxUserSeeks,
MAX(user_scans) AS MaxUserScans,
MAX(user_lookups) AS MaxUserLookups,
MAX(user_updates) AS MaxUserUpdates,
MAX(last_user_seek) AS MaxUserSeekDate,
MAX(last_user_scan) AS MaxUserScanDate,
MAX(last_user_lookup) AS MaxUserLookupDate,
MAX(last_user_update) AS MaxUserUpdateDate
FROM
sys.databases d
LEFT JOIN
sys.dm_db_index_usage_stats ius
ON ius.database_id = d.database_id
GROUP BY d.name
ORDER BY d.name

Załóżmy, że nie masz jak się zalogować do SQL server. Nie znasz hasła sla konta sa, żadna z grup, które miały dostęp sysadmina do systemu już nie istnieje. Możesz w trybie sngle user dodać użytkownika, który będzie miał uprawnienia sa:

1. Zatrzymaj SQL serwer

2. Uruchom go wykorzystując parametr -m. Uruchom cmd.exe jako administrator, przejdź do katalogu z binariami sql server (u mnie C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn) i uruchom:

sqlservr.exe -m

Nie zamykaj tego okienka!

3. uruchom nowy wiersz polecenia. Uruchom w nim sqlcmd:

sqlcmd

4 Wpisz komendy tworzące nowy login (tutaj o nazwie emergency) i dodające ten login do roli sysadmin:

CREATE login emergency with password=’****’
go
SP_ADDSRVROLEMEMBER emergency, sysadmin 
go

5. Zakończ proces uruchomiony w pkt. 2 naciskając CTRL+C

6. Uruchom SQL serwer normalnie i zaloguj się na nowo utworzone konto wybierając uwierzytelnienie SQL.

Jeśli użytkownicy nie mogą się zalogować, odpowiedni wpis powinien zostać zapisywany w errorlog SQL-a. Komunikaty wyświetlane użytkownikom są uboższe niż komunikaty widoczne w error logu. Właśnie znalazłem listę błędów z wyjaśnieniem, co te błędy dokładnie oznaczają:

http://sqlblog.com/blogs/aaron_bertrand/archive/2011/01/14/sql-server-v-next-denali-additional-states-for-error-18456.aspx

Korzystając z Azure można mieć bazę częściowo lokalnie, na swojej maszynie, a częściowo w chmurze w Azure. Konfiguracja była trochę trudna, dlatego opisałem ją tutaj trochę dokładniej. Wymagana podstawowa znajomość Azure. Nie tłumaczę pojęć, tylko pokazuję kroki:

1. Tworzysz storage i zakładasz na nim container:

2. Ściągasz Azure Storage Explorer w wersji 5

3. Dodajesz w Azure Storage Explorer Account powiązane z utworzonym wcześniej storage account

Klucz pobierasz z Azure, klikając na Manage Access Keys:

4. W Azure Storage Explorer, mając zaznaczony kontener, kliknij Security. Zaczynamy od zakładki Shared Access Policies. Stwórz tu policy o dowolnej nazwie, określ daty od kiedy do kiedy będzie wolno korzystać z plików w Azure.

Czytaj dalej »

SQL Server nie staruje. Cóż zajrzyj do dziennika zdarzeń. Ja znalazłem tu (w Administrative Events):

The MSSQLSERVER service was unable to log on as DOMENA\użytkownik
The MSSQLSERVER service was unable to log on as DOMENA\uzytkownik with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.

 Service: MSSQLSERVER
Domain and account: DOMENA\użytkownik
 This service account does not have the required user right „Log on as a service.”

Rzeczywiście. Uruchamiając SQL na koncie domenowym należy zadbać o to, aby konto posiadało uprawnienia do rejestru, plików oraz odpowiednie prawa przyznane w Local Security Policy. Zazwyczaj prawa te nadaje instalator, ale w tym przypadku stało się coś niedobrego.

Krótki rzut oka w dokumentację (https://msdn.microsoft.com/en-us/library/ms143504.aspx). Oto prawa wymagane przez usługę SQL:

• Log on as a service (SeServiceLogonRight)
• Replace a process-level token (SeAssignPrimaryTokenPrivilege)
• Bypass traverse checking (SeChangeNotifyPrivilege)
• Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

Mimo iż te uprawnienia są, to nadal występuje ten sam komunikat o błędzie! O co chodzi? Okazało się, że jakimś przypadkiem konto usługi SQL trafiło również do Deny log on as a service… A kiedy  w systemie Windows jeden wpis na coś pozwala, a drugi tego zabrania, to wygrywa zabraniający. Stąd błąd. Usunięcie konta z deny.. spowodowało, że SQL zaczął się uruchamiać.

Reporting Services pozwala na zautomatyzowanie wysyłania raportów dla użytkowników. Czasami jednak zdarza się, że raport, który ma być dostarczony jest pusty, lub się nie zmienił od poprzedniego razu. W aktualnej wersji SSRS nie ma opcji, która by to uwzględniała. Trzeba się odwołać do sztuczek.

Utwórz raport i schedule, który się już nie będzie automatycznie uruchamiał. W tym momencie SSRS tworzy job w SQL Agent, który uruchamia się wg schedule. Nazwa tego joba jest niezbyt przyjaznym UID-em
Stwórz własny job, który sprawdza, czy raport ma być wykonany. Wbuduj tu własną logikę. Sprawdź czy dane są, albo czy się zmieniły itp. Jeżeli warunek jest spełniony uruchom job stworzony przez SSRS!
Polecenie, które pozwoli skojarzyć konkretny raport z jobem:

            SELECT
                        Sch.ScheduleId AS  'Name of Job’,
                        Sch.LastRunTime,
                        U.UserName AS 'Created by’,
                        Cat.Name AS 'Report name’
            FROM [dbo].[Schedule]   Sch
            JOIN  [dbo].[ReportSchedule]  RSch ON Sch.ScheduleId = Sch.ScheduleId
            JOIN  [dbo].[Catalog] Cat ON Cat.ItemId =  RSch.ReportId
            JOIN dbo.Users U ON Sch.CreatedById = U.UserId 

Do uruchomienia joba z wykorzystaniem TSQL można wykorzystać następujący fragment kodu:

USE msdb ;
GO
EXEC dbo.sp_start_job N’Weekly Sales Data Backup’ ;
GO

Szczegóły dot. uruchamiania jobów z TSQL: https://msdn.microsoft.com/en-us/library/ms190774.aspx