4 pagine in totale: <<Indietro 1 2 3 [4]
Con le istruzioni seguenti fermiamo il servizio SQL Server sull'istanza che svolge il ruolo di Mirror, inseriamo dei record nel database Principal (inducendo un disallineamento tra i database) ed infine riavviamo l'istanza del database secondario. Si noti, nello script, la presenza dell'operatore !!: operando in SQLCMD mode con questa sintassi, viene eseguito un comando a livello di sistema operativo nella stessa finestra dove eseguiamo i normali comandi T-SQL.
--Stop del mirror
!!NET STOP MSSQL$Dallas
--Sul Principal vengono eseguite delle modifiche
INSERT dbo.MyTable VALUES ('Andrea')
INSERT dbo.MyTable VALUES ('Roberto')
GO
--Start del Mirror che acquisisce la coda e si riallinea
!!NET START MSSQL$Dallas
Nel test successivo eseguiamo ulteriori attività sul database, simuliamo il failover tra i database e verifichiamo infine la presenza, a seguito del failover, anche delle ultime istruzioni eseguite prima di tale evento. Effettuando la connessione al server che ospita il Mirror, lanciamo il seguente script:
USE master
GO
--Stop del Principal...
!!NET STOP MSSQL$Rome
--...ed il Mirror viene promosso. Dallas è il nuovo Principal
USE MyDB;
--Verifica che i dati sono allineati
SELECT * FROM dbo.MyTable;
--Eliminazione di un record
DELETE dbo.MyTable WHERE ID = 6;
GO
--Start del partner che riallinea i dati
!!NET START MSSQL$Rome
--Failover manuale per restituire a SQL2K5\Rome il ruolo di Principal
ALTER DATABASE MyDB SET PARTNER FAILOVER;
GO
Login Standard e utenti orfani
Se nel database sono presenti alcuni utenti che fanno riferimento a login di tipo standard, occorre prestare attenzione al cosiddetto "fenomeno degli utenti orfani".
Ad un primo riscontro superficiale, dopo aver eseguito il restore di un database su un server differente, potrebbe sembrare che il backup non porti con se i permessi sugli oggetti come erano definiti nel database originale. Tuttavia ad un esame più approfondito emerge che tutti gli utenti, con i relativi permessi, sono ancora presenti nel database ripristinato,anche se è stata rotta la mappatura tra lo user, ovvero colui che utilizza il database e che dispone dei permessi sugli oggetti (in maniera diretta o per mezzo dell'appartenenza ad un gruppo), ed il rispettivo login. Il legame tra login e user, rotto per ragioni di sicurezza dalla procedura di restore, può essere ripristinato eseguendo la sp_change_users_login come indicato dal Books On Line di SQL Server.
Anche nell'implementazione del database Mirror occorre tenere conto di questa caratteristica sia inizialmente (ripristino del database) che a seguito dell'aggiunta di un utente quando il database Mirror è già operativo.
Nell'istanza che ospita il database Principal creiamo quindi un login di tipo standard (attenzione che l'istanza sia configurata per consentire autenticazioni miste), nel database creiamo uno user mappato su tale login e infine assegnamo dei permessi allo stesso sulla tabella utilizzata per i nostri test.
USE master;
IF NOT EXISTS (
SELECT 1
FROM master.sys.server_principals
WHERE name = 'Luca')
CREATE LOGIN Luca WITH PASSWORD = 'Luca';
GO
USE MyDB;
CREATE USER Luca FOR LOGIN Luca;
GRANT SELECT ON dbo.MyTable TO Luca;
--Test di lettura
EXECUTE AS USER = 'Luca';
SELECT ID, Nome FROM dbo.MyTable;
REVERT;
GO
Sebbene lo user appena creato sia stato già riprodotto anche nel database Mirror, lo stesso non accade per il login in quanto quest'ultimo è un oggetto dell'istanza (e come tale memorizzato nel DB master) e non del database. Si rende quindi indispensabile creare il medesimo login nell'istanza che ospita il database Mirror e possiamo farlo aprendo una finestra di query sull'istanza oppure, ancora una volta, utilizzare le funzionalità offerte dalla modalità SQLCMD.
:connect SQL2K5\Dallas
IF NOT EXISTS (
SELECT 1
FROM master.sys.server_principals
WHERE name = 'Luca')
CREATE LOGIN Luca WITH PASSWORD = 'Luca';
Apriamo a questo punto una finestra di query sull'istanza che ospita il database Mirror e, sempre con l'impostazione SQLCMD mode, invertiamo i ruoli di Principal e Mirror.
:connect SQL2K5\Rome
ALTER DATABASE MyDB SET PARTNER FAILOVER;
Nella stessa finestra verifichiamo la presenza del login (a livello di istanza e creato in maniera esplicita) e dello user (a livello di database e quindi trasmesso dal processo di Mirror).
USE MyDB;
SELECT * FROM sys.server_principals;
SELECT * FROM sys.database_principals;
Ciò nonostante se mandiamo in esecuzione una query impersonando l'utente, la stessa non va a buon fine restituendo un messaggio di errore.
EXECUTE AS USER = 'Luca';
SELECT * FROM dbo.MyTable;
REVERT;
GO
Come accennato in precedenza il problema è da imputare al fatto che nessuno ha ancora detto a questa istanza di SQL Server che il login e lo user, sebbene abbiano lo stesso nome, devono essere legati fra loro. Con le istruzioni che seguono viene prima restituita una lista di tutti gli utenti orfani del database corrente e, con la seconda istruzione, viene effettuata la mappatura tra lo user ed il login con lo stesso nome. Infine, con l'ultima istruzione, viene ripristinato il ruolo originario di ciascuno dei database.
EXEC sp_change_users_login 'Report';
EXEC sp_change_users_login 'Update_One', 'Luca', 'Luca';
USE master;
ALTER DATABASE MyDB SET PARTNER FAILOVER;
Conclusioni
Come si è visto il database mirroring è una soluzione a basso costo e con ridotti oneri amministrativi in grado di aumentare la disponibilità di un database e rappresenta una risorsa di particolare interesse per quelle realtà di piccole e medie dimensioni dove non trova giustificazione l'implementazione di server in cluster. Tuttavia, anche laddove sia già presente un database server su cluster a due o più nodi, è possibile trarre beneficio dall'implementazione del mirroring per quei database per i quali la continuità di servizio rappresenta un fattore di primaria importanza.
In ogni caso il database mirroring, anche in congiunzione con altre soluzioni fault tolerant, non rappresenta una alternativa alla definizione di una efficace politica di disaster recovery basata sul backup regolare dei dati.
4 pagine in totale: <<Indietro 1 2 3 [4]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
