Brukerpålogginger og tillatelser på en database kan være feil etter at databasen er gjenopprettet


Symptomer


Hvis en dump av bruker en SQL Server-databasen er gjenopprettet til en annen SQL-Server (for eksempel en varm reserveserver) eller til den samme SQL-serveren etter enten gjenoppbygging eller lastes på en gammel versjon av hoveddatabasen, brukerpålogginger og tilgang til databasen kan være feil.

Dette problemet kan avsløre seg selv på flere måter:
  • Ved pålogging til en 6.x-server, kan brukere få følgende feilmelding:
    Msg 4002, nivå 14 tilstand 1, serveren Microsoft SQL Server, Line 0
    Påloggingen mislyktes
    DB-bibliotek: Logg feil.
  • Under pålogging til 7.0-servere, kan brukere få følgende feilmelding:
    Msg 18456, nivå-14, tilstand 1,
    Påloggingen mislyktes for brukeren '%ls'.
  • Under forsøk på å få tilgang til objekter i databasen, kan brukere få følgende feilmelding:
    Msg 229, nivå 14 State 1
    %s tillatelse nektet på objektet %. * s, databasen %. * s, eieren av %.*s
  • Under forsøk på å opprette en pålogging og gi tilgang til den gjenopprettede databasen eller legge til brukeren i databasen, kan du mottok følgende feilmelding:
    Microsoft SQL-DMO (ODBC-SQLState: 42000) feil 15023: brukerne eller rollene '%s' finnes allerede i den gjeldende databasen.
  • Brukere kan ha tillatelsene på objekter som de tidligere ikke.

Årsak


Brukerens påloggingsinformasjon er lagret i syslogins-tabellen i hoveddatabasen. Ved å endre servere, eller ved å endre denne informasjonen ved å bygge på nytt eller gjenopprette en gammel versjon av hoveddatabasen, kan informasjonen være forskjellig fra når de bruker databasen dump ble opprettet. Hvis pålogginger ikke finnes for brukere, vil de motta en feilmelding om "Pålogging mislyktes" under forsøk på å logge serveren. Hvis brukerpålogginger eksisterer, men til SUID-verdier (for 6.x) eller SID (for 7.0) i original... syslogins og sysusers-tabellen i brukerdatabasen forskjellige, og brukerne kan ha andre tillatelser enn forventet i brukerdatabasen.

Obs! Hvis du bruker Microsoft SQL Server 2005, implementeres syslogins -tabellen og tabellen sysusers som kompatibilitet visninger. Disse visningene er sys.syslogins og sys.sysusers. Hvis du vil ha mer informasjon om kompatibilitet visninger, kan du se emnet "Compatibility visninger (Transact-SQL)" i SQL Server 2005 Books Online.

Løsning


Hvis du vil omgå dette problemet, gjør du ett av følgende:
  • Hvis gjeldende skript er tilgjengelig for å legge til pålogginger, brukere og tillatelser, kan du slette og opprette dem på nytt fra skript. Eksempler på bruk av skript til å overføre pålogginger mellom servere, kan du se følgende artikkel i Microsoft Knowledge Base:
    246133 slik: overføre pålogginger og passord mellom forekomstene av SQLServer

    240872 hvordan du løser problemer med tillatelse når en Database flyttes mellom SQL-servere
  • Du kan bruke sp_change_users_login lagret fremgangsmåte for å knytte relasjonene mellom tabellene syslogins, sysusers og sysalternates. Imidlertid prosedyren gjør beste beregningene på koblinger, og kan tillate at en bruker mer tilgang enn ønsket. Kjører prosedyren med rapportalternativet vil først generere en liste over brukere som vil bli endret. Etterpå, bør du kontrollere for å sikre at de påvirkede brukerne har de riktige tillatelsene. Vær også oppmerksom på at sp_change_users_login-prosedyren ikke løser tillatelse problemer som er avledet fra pålogginger og brukere som er opprettet i en annen rekkefølge på databasen der sikkerhetskopien er gjenopprettet.
  • Gjenopprette en dump av hoveddatabasen fra tidspunktet for bruker databasen dump på serveren før du laster inn brukerdatabasen. Dette sikrer at alle brukerinformasjon i brukerdatabasen, samsvarer med riktig syslogins-tabellen i malen.


    Advarsel: hoveddatabasen inneholder informasjon for hele serveren, og påvirker alle databaser på serveren. Ved å gjenopprette hoveddatabasen, kan det oppstå flere bruker-IDer og/eller databaser som er tapt eller har feil tillatelser. Endringer i malen som har oppstått etter tidspunktet for sikkerhetskopiering, vil gå tapt. Bare Bruk denne metoden hvis du er sikker på at sikkerhetskopi av hoveddatabasen inneholder nøyaktig informasjon for den aktuelle brukerdatabasen og alle andre databaser på serveren.
  • Bruk overføring leder (for 6.x) eller DTS (for 7.0) til å kopiere påloggingene. Vær oppmerksom på at passord ikke overføres ved hjelp av denne metoden.
  • Kontakt din primære kundestøtteleverandør.