Blog

  • +
    Workshop: Hands-on Oracle Database Appliance | Thiene – 26 novembre
  • +
    Voucher per l’Innovation Manager
  • +
    Miriade a Università Aperta IES Padova
  • +
    DevOps in azienda, come, dove, quando e perché?
  • +
    AWSome Day Padova, il racconto dell’evento
  • cloud digital transformation social
    +
    Il cloud al centro della digital transformation
  • +
    Webinar ODA e Dbvisit Standby: scopri come semplificare la gestione del tuo database | 26 settembre
  • SOPHOS EVOLVE
    +
    Il futuro della cybersecurity ti aspetta a Verona e Roma con Sophos Evolve
  • Google Hangouts Meet
    +
    È il momento di ridisegnare la tua sala riunioni con gli hardware Google
  • +
    Arcadia Data accelera gli insight di Cloudera
  • +
    Sicurezza IT: come migliorare la fiducia in azienda
  • +
    CORSO FAST TRACK ADMIN: UPGRADE ALLA VERSIONE G SUITE BUSINESS

Le vie del backup sono infinite

By Camilla Mantella 5 anni faNo Comments

Quella che presentiamo oggi è una soluzione di disaster recovery messa a punto da Microsoft per la propria tecnologia di database SQL Server: il LOG SHIPPING.

Di cosa si tratta

Dietro a questo nome si nasconde un concetto molto semplice. Il log shipping permette, come suggerisce il nome, di mantenere allineati un database primario, attivo in produzione, ed il relativo database secondario, di standby, grazie alla “spedizione” del transaction-log dal server principale a quello secondario. In questo modo tutte le transazioni avvenute sul db principale vengono successivamente applicate anche al db in standby. In caso di failure del db primario basterà dunque promuovere il database secondario al ruolo di primario con una semplice procedura evitando lunghi fermi di produzione. Non solo, il log shipping offre anche la possibilità di impostare il ritardo con cui viene applicato il log delle transazioni facendo sì che il db secondario possa essere allineato, per esempio, alla situazione del db primario di sei ore prima. Questo significa che se dovessimo erroneamente cancellare la più importante delle nostre tabelle in produzione non dovremo più temere per il nostro posto di lavoro: sarà sufficiente applicare al db secondario tutte le transazioni fino alla fatidica cancellazione della tabella e promuoverlo al ruolo di db primario.

Ecco perché proponiamo questa soluzione ai nostri clienti, sapendo quanto questi dati siano per loro irrinunciabili. Inoltre questo metodo è un’ alternativa al backup full del db primario. Infatti accade talvolta che il backup full del db provochi dei rallentamenti che non possono essere accettabili, in un ambiente di produzione.
Le vie del backup sono davvero infinite😉!

Per saperne di più clicca qui.

Category:
  Database
this post was shared 0 times
 000

Leave a Reply

Your email address will not be published.