[SQL] inactieve databases achterhalen

[jokko]

Beste,

Momenteel zit ik bij een nieuw bedrijf waar niemand mij kan vertellen waar voor veel databases voor dienen.
Graag wil ik daarom een grote schoonmaak gaan houden in SQL.
Het betreft een omgeving met 4 SQL instance op 2014 en nog 2 SQL express.

Mijn vraag ik dus hoe ik kan zien of er nog activiteit is op een database door middel van "last modified" bijvoorbeeld. Zelf heb ik we al kunnen achterhalen met een query of er connecties zijn naar de DB dit kwam uit op 0 bij heel veel databases. Echter wil ik het eerst zeker weten voor ik hem op offline zet.

Zelf ben ik niet goed met SQL dus vandaar mogelijk mij standaard vraag
Hopelijk weten jullie hier een oplossing voor of mogelijk een betere !

[Redshark]

Eeh, misschien gewoon dit (nog) niet doen? Als niemand kan vertellen waarvoor een DB gebruikt wordt wil dat nog niet zeggen dat het ding geen nut heeft. Je verwijderd het sneller dan je het weer ongedaan hebt gemaakt wanneer dit toch nodig blijkt.

Zelf heb ik we al kunnen achterhalen met een query of er connecties zijn naar de DB dit kwam uit op 0 bij heel veel databases

Dit zullen het aantal actieve queries zijn denk ik? Als het gebruik van een DB weinig is zul je ongetwijfeld ook weinig tot geen actieve connecties hebben.

[Jarrean]

Je zou met SQL profiler kunnen kijken of er querries langs komen, deze een dagje open laten staan voor de zekerheid.

[DJMaze]

Dagje?
Ik heb databases die ik meer dan een jaar niet aanraak (test db klant bijvoorbeeld) en dan heeft de klant opeens een vraag en ben ik een week actief op die DB.
Het is natuurlijk niet de bedoeling dat je de live database binnen harkt, want dan heb je weer met de GDPR en andere zaken te maken.

Maak gewoon een backup van de inactieve DB's en daarna kan je ze verwijderen.
Mocht je alsnog ooit eentje nodig hebben kan je de backup terug zetten.

[The Eagle]

Een DB beheerder die niet zo bekend is met SQL naja, al doende leert men
Kan nooit om veel data gaan, zeker niet met die SQL express doosjes. Je zou kunnen achterhalen waar de connecties vandaan komen (windows logs, SQL logs) en van daar uit verder zoeken om welke applicatie het gaat. En dan degene waar die aplicatie bij hoort aan zijn jasje trekken wat ie loopt te prutten en of het weg kan.

Piepmethode kan ook. Gewoon een week (inclusief weekend, je zou een batchjob misen) de SQL instance monitoren en dan een shutdown geven. Dan nog een week wachten en dan in een full backup. Ding restoren op een andere machine om je backup te testen, en werkt dat dan de originele wieberen.

[jokko]

The Eagle schreef op donderdag 5 april 2018 @ 14:52:
Een DB beheerder die niet zo bekend is met SQL naja, al doende leert men
Kan nooit om veel data gaan, zeker niet met die SQL express doosjes. Je zou kunnen achterhalen waar de connecties vandaan komen (windows logs, SQL logs) en van daar uit verder zoeken om welke applicatie het gaat. En dan degene waar die aplicatie bij hoort aan zijn jasje trekken wat ie loopt te prutten en of het weg kan.

Piepmethode kan ook. Gewoon een week (inclusief weekend, je zou een batchjob misen) de SQL instance monitoren en dan een shutdown geven. Dan nog een week wachten en dan in een full backup. Ding restoren op een andere machine om je backup te testen, en werkt dat dan de originele wieberen.

Ik heb nooit gezegd dat ik DB beheerder ben, ik zit meer in vmware en windows enz. helaas hoort daar soms ook een vraag vanuit SQL bij die ik graag zou willen op pakken om wat nieuws te leren.

Maar ik denk inderdaad dat ik er een aantal offline breng voor twee weken en bij geen gehoor ze verwijder.

[TeraMod]

Onbekende DBs rename naar z_oldname, kun je heel snel weer terug mocht blijken dat het ding toch actief is

[Henkje.doc]

Van belang is om in kaart te brengen om welke databases het gaat, en of dit niet toevallig gaat om databases die slechts enkele malen per jaar worden geraadpleegd.
Incidenteel controleren of er actieve processen zijn kan helpen, maar geeft niet altijd een direct beeld.

Wat ik zelf bij twijfel nog wel eens doe is een job je maken wat een bepaalde periode de sys.sysprocesses ophaalt:

select * from sys.sysprocesses where db_name(dbid)='$databasenaam'
$Databasenaam is dan de database die je wilt controleren

Als je dit scriptje dan om de 5 minuten een periode laat lopen via de SQL agent, dan krijg je een beeld welke connecties er zijn. Als dit er helemaal geen zijn dan kun je inderdaad de piepmethode hanteren, al zou ik dit bij een grotere organisatie niet zo snel doen.

[F_J_K]

Er zijn idd zat voorbeelden van databases die misschien een keer per jaar worden gebruikt. Desondanks mag je verwachten dat van alle (server)software en databases enige documentatie bestaat van hoe en wat. Tenminste op afdelingsniveau, liefst organisatiebreed. (Zeg ik naïef )

DJMaze schreef op donderdag 5 april 2018 @ 14:33:
Het is natuurlijk niet de bedoeling dat je de live database binnen harkt, want dan heb je weer met de GDPR en andere zaken te maken.

Mja, diezelfde GDPR zal het een zonde vinden als je databases vol persoonsgegevens hebt waar niemand een idee van heeft waarom het er is, wat er in staat, wie toegang heeft, of er ueberhaupt fatsoenlijke autorisatie etc is, of er enige beveiligingspatches worden doorgevoerd, etc. Hier wordt heel erg niet voldaan aan de belangrijkste beginselen van verwerking. Dan is - met toestemming en evt met twee paar ogen - kijken wat er in de DB staat IMHO veruit het minst vd twee kwaden.

(Mits er persoonsgegevens in staan dan. Maar als niet dan is kijken vast ook niet erg, er van uitgaande dat de TS niet bij de AIVD werkt )

Maak gewoon een backup van de inactieve DB's en daarna kan je ze verwijderen.
Mocht je alsnog ooit eentje nodig hebben kan je de backup terug zetten.

Zoiets ja. Zorg dat het heel snel terug kan worden gezet wanneer wordt gepiept.