MSSQL Database restore met replace, lijkt niet te werken.

[Defector]

Regelmatig restore ik een database via het SQL commando.

Restore Database "databasenaam" from disk "filenaam" with recovery, replace, stats

Nu wil het geval dat de database die ik restore nieuwe kolommen bevat in de tabellen.
Ben verder compleet niet geïnteresseerd in de oude database.
De nieuwe database met alles wat erbij hoort (data en tabel definitie) moet gewoon onder "Databasenaam" weer aanwezig zijn in de MSSQL server.

Ik ging er altijd vanuit dat replace daar het juiste commando voor was. Maar nu loop ik tegen een issue aan dat bepaalde kolommen niet meegenomen zijn vanuit de nieuwe database.
Al een keer geverifieerd of ik de juiste database had en het nog een 2e keer uitgevoerd. Maar die kolommen blijven afwezig.

[RobIII]

Uh, dan doe je volgens mij toch echt iets verkeerd of verwar je bestanden met elkaar o.i.d. Dit zou gewoon moeten werken en een volledige restore moeten doen, niet alles-op-een-paar-kolommen-na.

[Defector]

Thanks voor de bevestiging, het gebruikte commando zit dan goed. Dan moet ik het ergens anders zoeken waarom het niet werkt.

[Wim-Bart]

Waarom niet gewoon een sql file van database aanmaken en die uitvoeren waarbij oude database gedropt wordt. Veel sneller en je hebt een schone database.

Overigens een restore met replace gaat ook fout wanneer er nog een connectie open staat of een backup loopt.

[Gomez12]

Wim-Bart schreef op zaterdag 20 juni 2020 @ 22:39:
Waarom niet gewoon een sql file van database aanmaken en die uitvoeren waarbij oude database gedropt wordt. Veel sneller en je hebt een schone database.

Hoe bedoel je sneller?
Heb je daar enigszins timings oid van? Want het lijkt mij heel erg vreemd dat een sql-file die eerst door een parser dan nog door een query-optimizer moet sneller is dan een binair formaat.

TS: Wat voor backup (full/incremental/log) is het exact? Want in principe zijn het geen nieuwe kolommen. Je hebt als het goed is gewoon in je database kolommen staan en die worden gewoon gerestored of de restore mislukt.

Maar standaard backup van sql server kan geen kolommen uitsluiten.

[Defector]

Ben even van scratch begonnen met nieuwe back-ups en opnieuw inlezen. Had wat problemen met de database die een verbinding vast bleef houden. Nadat ik de database offline had gezet en weer online was het gelukt. Waarbij de juiste gegevens nu ook over zijn genomen.

Het was een full backup.

[Wim-Bart]

Gomez12 schreef op zondag 21 juni 2020 @ 16:56:
[...]

Hoe bedoel je sneller?
Heb je daar enigszins timings oid van? Want het lijkt mij heel erg vreemd dat een sql-file die eerst door een parser dan nog door een query-optimizer moet sneller is dan een binair formaat.

TS: Wat voor backup (full/incremental/log) is het exact? Want in principe zijn het geen nieuwe kolommen. Je hebt als het goed is gewoon in je database kolommen staan en die worden gewoon gerestored of de restore mislukt.

Maar standaard backup van sql server kan geen kolommen uitsluiten.

Afhankelijk van de database praat je hier over milliseconden. Een restore met replace is sowieso trager dan een restore na een drop van een database omdat er veel meer moet plaats vinden intern. En zolang je geen data mee hoeft te restoren is een nieuwe db genereren met een script ook veel fijner, met name omdat je dan tenminste ook met autonumbering op 1 begint.

[Wim-Bart]

Defector schreef op zondag 21 juni 2020 @ 22:56:
Ben even van scratch begonnen met nieuwe back-ups en opnieuw inlezen. Had wat problemen met de database die een verbinding vast bleef houden. Nadat ik de database offline had gezet en weer online was het gelukt. Waarbij de juiste gegevens nu ook over zijn genomen.

Het was een full backup.

Dus blijkbaar stonden er nog locks. connecties of transacties open. Offline zetten zorgt voor er voor dat de database "vrij" is en dan gaat restoren vlekkeloos.

[Gomez12]

Wim-Bart schreef op zondag 21 juni 2020 @ 23:13:
[...]
Afhankelijk van de database praat je hier over milliseconden. Een restore met replace is sowieso trager dan een restore na een drop van een database omdat er veel meer moet plaats vinden intern. En zolang je geen data mee hoeft te restoren is een nieuwe db genereren met een script ook veel fijner, met name omdat je dan tenminste ook met autonumbering op 1 begint.

Ah, jij scheidt de data van de database. Terwijl de TS expliciet zegt inclusief data.

En imho hoort bij een restore altijd data, ik ken geen mogelijkheid om van een db fatsoenlijk alleen de structuur te backuppen om die ergens anders weer te gaan restoren.

Juist vanwege oa autonumbering die in een andere tabel een FK is en daar gewoon als data meegebackupped is en dus niet meer zou kloppen als die op 1 begint.

Je kan een dbase scriptmatig opbouwen en de structuur scriptmatig beheren, maar dat is iets anders dan backup/restore.

Ik denk dat wat TS gewoon zo af en toe doet is : Een productie omgeving database overzetten naar een acceptate / test-omgeving. Zodat de mensen die moeten testen / accepteren tegen voor hun bekende data aan zitten te kijken.

[Wim-Bart]

Gomez12 schreef op zondag 21 juni 2020 @ 23:26:
[...]

Ah, jij scheidt de data van de database. Terwijl de TS expliciet zegt inclusief data.

En imho hoort bij een restore altijd data, ik ken geen mogelijkheid om van een db fatsoenlijk alleen de structuur te backuppen om die ergens anders weer te gaan restoren.

Juist vanwege oa autonumbering die in een andere tabel een FK is en daar gewoon als data meegebackupped is en dus niet meer zou kloppen als die op 1 begint.

Je kan een dbase scriptmatig opbouwen en de structuur scriptmatig beheren, maar dat is iets anders dan backup/restore.

Ik denk dat wat TS gewoon zo af en toe doet is : Een productie omgeving database overzetten naar een acceptate / test-omgeving. Zodat de mensen die moeten testen / accepteren tegen voor hun bekende data aan zitten te kijken.

Ik ging er van uit dat data niet belangrijk was, omdat dit ook werd gezegd. Wanneer ik een restore zou doen van dev/acc/tst dan zou ik dat zonder data doen. Er vanuit gaande dat dit ook het geval zou zijn. En eventuele data, zoals bijvoorbeeld lookup tabellen, zou ik dan ook gescript vullen met bulk import bijvoorbeeld.

[Gomez12]

Wim-Bart schreef op zondag 21 juni 2020 @ 23:34:
[...]

Ik ging er van uit dat data niet belangrijk was, omdat dit ook werd gezegd.

Gewoon even ter mijner info, maar waar lees jij dat want ik lees juist het tegenovergestelde :

De nieuwe database met alles wat erbij hoort (data en tabel definitie) moet gewoon onder "Databasenaam" weer aanwezig zijn in de MSSQL server.

Nieuwe database = gerestorede database neem ik aan.

Defector schreef op zondag 21 juni 2020 @ 22:56:
Ben even van scratch begonnen met nieuwe back-ups en opnieuw inlezen. Had wat problemen met de database die een verbinding vast bleef houden. Nadat ik de database offline had gezet en weer online was het gelukt. Waarbij de juiste gegevens nu ook over zijn genomen.

Het was een full backup.

Dan zou ik bij deze even goed gaan kijken naar error-handeling, want een restore die mislukt aanzien voor een restore die wat kolommen mist is toch echt een wezenlijk verschil...

[Wim-Bart]

Gomez12 schreef op maandag 22 juni 2020 @ 00:22:
[...]

Gewoon even ter mijner info, maar waar lees jij dat want ik lees juist het tegenovergestelde :

[...]

Nieuwe database = gerestorede database neem ik aan.

Ik werd in verwarring gebracht door:
Ben verder compleet niet geïnteresseerd in de oude database.
Dus data weg.

En:
Nu wil het geval dat de database die ik restore nieuwe kolommen bevat in de tabellen.
Dus dacht ik, een compleet nieuw schema.