Corso SQL per DBA

2,447 views

Published on

Primo insieme di slide del corso SQL Server 2008 R2 tenuto presso ENAIP FVG di Udine nell'ambito del corso di progettazione di basi di dati in ambiente Access e SQL Server.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,447
On SlideShare
0
From Embeds
0
Number of Embeds
747
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Corso SQL per DBA

  1. 1. Dr.  Paolo  Casoto,  Ph.  D.,  2012   Dr.  Paolo  Casoto,  Ph.D,  2012   1  
  2. 2. Dr.  Paolo  Casoto,  Ph.D,  2012   2  
  3. 3.   Database  Management  System  (DMS)   caratterizzato  da  una  elevata  versatilità     DB  di  pochi  MB  su  dispositivo  mobile     DB  distribuito  da  molteplici  GB    Insieme  di  componenti,  servizi  e  strumenti     Il  tutto  costruito  attorno  alla  componente   principale,  il  Database  Engine   ▪  Servizio  di  Windows  dedicato  alla  memorizzazione  e   all’elaborazione  di  dati…   Dr.  Paolo  Casoto,  Ph.D,  2012   3  
  4. 4.   Ma  che  tipologia  di  dati  ?     Dati  relazionali     Dati  spaziali     Documenti  in  formato  XML    Elaborare  dati  implica:     Memorizzare  i  dati  in  modo  sicuro     Consentire  un  accesso  veloce  ma  consistente  ai  dati     Gestire  la  politica  di  sicurezza  di  accesso  ai  dati     Gestire  l’integrità  dei  dati   Dr.  Paolo  Casoto,  Ph.D,  2012   4  
  5. 5.   Gestire  la  memorizzazione  delle  righe  che   compongono  il  db  all’interno  di  strutture  dati   indipendente  dalla  specifica  infrastruttura   HW  sottostante     Pagine  da  8KB  raggruppate  in  Extent  da  8  Pagine    Gestire  la  memorizzazione  dell’insieme  di   modifiche  che  hanno  luogo  sui  dati     Memorizzazione  del  log  delle  transazioni.   Dr.  Paolo  Casoto,  Ph.D,  2012   5  
  6. 6.   Utilizzo  di  indici  per  la  ricerca  ottimizzata  dei   dati  memorizzati    Utilizzo  della  memoria  cache  quale  strumento  di   velocizzazione  dell’accesso  al  disco  fisso    Grazie  alla  gestione  nell’ordine  di  esecuzione   delle  operazioni  e  della  concorrenza  il  DMS  è  in   grado  di  garantire  un  costante  accesso  a  dati  in   stato  consistente     Non  rischio  che  un  altro  utente  modifichi  ciò  che  sto   leggendo  in  questo  specifico  istante.   Dr.  Paolo  Casoto,  Ph.D,  2012   6  
  7. 7.   Gestione  di  un  insieme  multilivello  di  strumenti   di  controllo  dell’accesso  ai  dati  da  parte  degli   utenti    Gestione  dei  protocolli  di  accesso  via  rete    Possibilità  di  impostare  un  insieme  di  regole  da   applicare  ai  dati  per  garantire  la  consistenza   degli  stessi  a  livello  di  database     Sposto  la  logica  di  controllo  di  consistenza  dei  dati   all’interno  del  DMS  e  non  più  a  livello  applicativo   ▪  Vedremo…  non  sempre  questa  scelta  si  rivelerà  la  migliore   Dr.  Paolo  Casoto,  Ph.D,  2012   7  
  8. 8.   Standard  Edition:  versione  destinata  al  pubblico   più  ampio;  fino  a  4  CPU  e  senza  limiti   dimensionali  ai  singoli  DB     Adatto  a  tutte  le  infrastrutture  di  dimensione  media  e   medio-­‐bassa    Enterprise  Edition:  versione  destinata  alle  realtà   che  hanno  bisogno  di  performance  e  scalabitità     Grandi  portali  web,  data  warehouse,  sistemi  OLTP     Gestione  di  molteplici  funzionalità  basate  su   architettura  parallela   ▪  E.g.:  query  parallele   Dr.  Paolo  Casoto,  Ph.D,  2012   8  
  9. 9.   Express  Edition:  versione  gratuita  utilizzata  nel   caso  di  infrastrutture  con  db  locale       nell’ambito  di  infrastrutture  client  server  per  la   gestione  della  temporanea  assenza  di  connettività     Limite  alla  dimensione  di  singoli  db  e  della  memoria   utilizzabile  dalla  CPU.    Vi  sono  inoltre  versioni  particolari  delle   precedenti:     Workgroup,  web,  developer,  datacenter  et  al.     Varianti  delle  precedenti  connotate  per  specifici  ersione   Noi  useremo  la  v utilizzi   Express    Per  gli  esercizi   a  casa  è  sufficiente   Dr.  Paolo  Casoto,  Ph.D,  2012   9  
  10. 10.   Le  licenze  di  SQL  Server  2008  R2  (ed  il   relativo  costo)  si  basano  su  molteplici   elementi  funzionali  dell’infrastruttura:     Per  numero  di  utenti     Per  numero  di  dispositivi  utilizzati  per  l’accesso   all’engine  del  database     Per  numero  di  processori  utilizzati  in  fase  di   esecuzione  del  processo  lato  server     Et  al.  …  ma  non  è  una  priorità  di  questo  corso     Dr.  Paolo  Casoto,  Ph.D,  2012   10  
  11. 11.   SQL  Server  Management  Studio  (SSMS):   strumento  di  amministrazione,  per  il  controllo   completo  del  Database  Engine     Creazione  e  progettazione  database  e  tabelle     Gestione  server  (e.g.:  risorse,  localizzazione)     Gestione  funzionalità  ed  accessori     Gestione  politiche  di  accesso     Esecuzione  di  query  T-­‐SQL    Dalla  versione  11  è  scritto  in  WPF  su   ambiente  .NET   Cosa  significa  ?  Lo   scopriremo  insieme   Dr.  Paolo  Casoto,  Ph.D,  2012   11  
  12. 12.   SQL  Server  Configuration  Manager:  utilizzato  per  la   gestione  del  servizio  SQL  (e.g.:  avvio,  spegnimento)  e   dei  protocolli  di  rete  abilitati  all’accesso.    SQL  Server  Agent:  strumento  per  lo  scheduling  di   attività  di  manutenzione  e  di  script  di  controllo  e   gestione.     Servizio  di  Windows       Possibilità  di  eseguire  le  medesime  attività  su  più  server   SQL  mantenendo  un  punto  di  controllo  centralizzato  sulle   attività   ▪  10  server  devono  eseguire  il  medesimo  script  di  manutenzione   programmata.   Dr.  Paolo  Casoto,  Ph.D,  2012   12  
  13. 13.   SQL  Server  Profiler:  strumento  grafico  per   l’analisi  delle  performance  del  server  SQL       Consente  di  “catturare”  tutte  le  attività  che  sono   svolte  dal  server  per  ciascuna  interazione  con   l’utente     Controllo  delle  performance  di  ciascuna  query     Controllo  delle  procedure  di  accesso  al  sistema     Controllo  del  codice  eseguito  per  ciascuna   chiamata  a  funzione  o  stored  procedure.   Dr.  Paolo  Casoto,  Ph.D,  2012   13  
  14. 14.   Procedura  lato  server  per  la  copia  di  una   istanza  di  SQL  Server  da  e  verso  un’altra   istanza  della  stessa  piattaforma  e/o  un   diverso  DMS     E.g.:  da  SQL  ad  Access    Tre  tipologie  di  replicazione:     Snapshot     Replica  transazionale     Fusione   Dr.  Paolo  Casoto,  Ph.D,  2012   14  
  15. 15.   In  fase  di  installazione  è  possibile  definire  quali   funzionalità  aggiuntive  attivare  a  supporto  del   DBMS     E.g.:  Reporting  Service,  Analysis  Service,  servizi   condivisi,  accessori,  et  al.     E’  possibile  installare  all’interno  della  stessa   macchina  più  istanze  del  DB  engine     Esecuzione  indipendente,  ciascuna  istanza  con  un   proprio  servizio     Attenzione:  stiamo  parlando  di  DB  engine  e  non   ancora  di  DB  !!!     ▪  Più  DB  possono  comunque  coesistere  sullo  stesso  DB  engine    Ciascuna  istanza  del  DB  engine  è  caratterizzata  da  un  nome  univoco  !h.D,  2012   Dr.  Paolo  Casoto,  P !!   15  
  16. 16.   Definire  gli  utenti  di  sistema  che  saranno   utilizzati  per  l’avvio  del  servizio  SQL  Server     Definire  un  utente  per  ciascuna  istanza  del   servizio  in  caso  di  installazioni  multiple   all’interno  della  stessa  macchina.     Se  selezionate  l’utente  Local  System  (default),   non  avrete  accesso  ad  alcuna  risorsa  di  rete.    Gestire  la  collocazione  dei  file  dei  db  e  dei  file   di  log  dell’engine   Dr.  Paolo  Casoto,  Ph.D,  2012   16  
  17. 17.   In  generale  è  bene  rispettare  le  seguenti   indicazioni:     Posizionare  per  motivi  di  sicurezza  e  performance  i  file   del  db  ed  i  file  di  log  all’interno  di  dischi  fra  loro   differenti   ▪  Meglio  se  ad  utilizzo  esclusivo   ▪  Meglio  se  caratterizzati  da  elevate  performance  (e.g.  SSD)     In  particolare  prestare  attenzione  alla  collocazione  dei   file  del  db  tempdb   ▪  Anche  in  questo  caso  è  consigliabile  l’utilizzo  di  un  disco   dedicato,  al  fine  di  ottimizzarne  le  performance.   Dr.  Paolo  Casoto,  Ph.D,  2012   17  
  18. 18.   Il  wizard  del  tool  di  installazione  /  upgrade   consente  la  gestione  di  tutte  le  casistiche  quali:     Installazione  di  una  nuova  istanza  di  SQL  Server  2008   R2  in  assenza  di  altre  istanze  SQL  Server  2008  R2  sulla   stessa  macchina     Installazione  di  una  istanza  di  SQL  Server  2008  R2  in   presenza  di  altre  istanze  SQL  Server  2008  R2  sulla   stessa  macchina     Aggiornamento  dalle  versioni  precedenti     Ripristino  del  sistema   Dr.  Paolo  Casoto,  Ph.D,  2012   18  
  19. 19.   E’  necessario  definire  quali  protocolli  il   servizio  SQL  Server  deve  supportare,  al  fine  di   consentire  la  connessione  da  parte  dei  client    Client  supportati  nella  versione  2008  R2:     Named  Pipes   Alcune  tipologie  di  client,  come  i  client  con   protocollo  AppleTalk,  sono  stati  rimossi  nel     Shared  Memory   corso  delle  versioni  di  SQL  Server     TCP  /  IP     Virtual  Interface  Adapter  (VIA)   Dr.  Paolo  Casoto,  Ph.D,  2012   19  
  20. 20. Per  configurare  i  client  attivi  dell’istanza  del  db   engine  possiamo  utilizzare  il  tool  di   configurazione  di  SQL  Server  incluso   nell’installazione   Sicurezza  e  performance   sono  vincolare  ai   protocolli  selezionati:   utilizzare  solo  i  protocolli   necessari  rispetto  alla   specifica  istanza  Dr.  Paolo  Casoto,  Ph.D,  2012   20  
  21. 21.   Il  protocollo  da  utilizzarsi  in  ambito  di   connessioni  esclusivamente  locali  è  il   protocollo  shared  memory     Opera  solo  se  client  e  server  risiedono  all’interno   della  stessa  macchina     Utilizzato  da  SQL  Server  Management  Studio  per   la  connessione  locale     Protocollo  sicuro  per  definizione   ▪  Posso  avviare  un  processo  client  rispetto  al  db  solo  se  ho   accesso  alla  macchina  stessa  ove  risiede  il  servizio  server   Dr.  Paolo  Casoto,  Ph.D,  2012   21  
  22. 22.   Le  connessioni  di  rete  sono,  per  default,   disabilitate.     E’  importante  ricordarsi,  in  caso  di  prima  installazione   del  server,  attivare  le  connessioni  di  rete  necessarie   ▪  In  generale  può  bastare  la  connessione  TCP/IP   ▪  La  porta  di  default  è  la  1433     E’  possibile  definire  molteplici  regole  di  connessione   per  abilitare  specifici  insiemi  di  utenti     ▪  Attenzione,  parliamo  ancora  di  connessione  a  livello  TCP/IP.   Non  abbiamo  ancora  parlato  di  autenticazione  vera  e  propria   al  db  engine   ▪  E.g.:  solo  gli  utenti  all’interno  di  un  determinato  insieme  di   indirizzi  IP  possono  accedere  in  modalità  TCP/IP   Dr.  Paolo  Casoto,  Ph.D,  2012   22  
  23. 23.   In  realtà  il  client  non  si  connette  direttamente  al   db  engine.     Il  servizio  SQL  Browser  si  occupa  di  gestire  le   connessioni  al  db  anche  in  presenza  di  molteplici   istanze  dello  stesso     Il  client  richiede  al  SQL  Browser  la  connessione  ad  una   specifica  istanza  nominata   ▪  Il  servizio  SQL  Browser  identifica  l’istanza  associata  al  nome   fornito  dal  client  e  genera  la  connessione  allo  specifico  db   engine     Non  ci  credete  ?  Provate  a  spegnere  il  servizio  SQL   Browser  ed  ad  avviare  SQL  Server  Management   Studio…   Dr.  Paolo  Casoto,  Ph.D,  2012   23  
  24. 24. Le  3  istanze  di  SQL  ed  il   SQL  Browser  sono  servizi   in  esecuzione  sulla   macchina  server   DB   DB   DB  ENGINE  1   ENGINE  2   ENGINE  3   SQL  Browser   Vorrei   Vorrei   connettermi   connettermi   ad  ENGINE  1   ad  ENGINE  2   Dr.  Paolo  Casoto,  Ph.D,  2012   24  
  25. 25.   Per  l’istanza  di  default,  l’attivazione  del  protocollo   TCP/IP  su  SQL  Server  2008  R2  comporta:     Possibilità  per  ogni  indirizzo  IP  di  accedere  alla  porta  1433    Per  l’istanza  nominata,  l’attivazione  del  protocollo   TCP/IP  su  SQL  Server  2008  R2  comporta:     Possibilità  per  ogni  indirizzo  IP  ad  una  porta  TCP  assegnata   all’avvio  del  processo   ▪  Non  posso  avere  più  processi  in  ascolto  sulla  stessa  porta,  ergo  devo   assegnare  l’indirizzo  della  porta  dinamicamente    Nel  caso  siano  presenti  una  o  più  istanze  nominate   SQL  Browser  consente  di  astrarre  rispetto  alla   specifica  porta  associata  ad  una  istanza     Funge  da  risolutore  delle  porte  TCP/IP   Dr.  Paolo  Casoto,  Ph.D,  2012   25  
  26. 26. Dr.  Paolo  Casoto,  Ph.D,  2012   26  
  27. 27.   SQL  Server  utilizza  un  insieme  di  oggetti  del   Database  Engine  per  il  proprio  funzionamento     Database  di  sistema     Tabelle  di  sistema     Funzioni  e  SP  di  sistema    Il  funzionamento  e  la  manutenzione  delle  tabelle   di  sistema  è  un  argomento  che  riguarda   principalmente  gli  amministratori  del  DB     Per  il  programmatore  il  tutto  è  alquanto  trasparente   Dr.  Paolo  Casoto,  Ph.D,  2012   27  
  28. 28.   Esistono  all’interno  di  ciascuna  istanza  di  SQL   Server  alcuni  DB  che  sono  utilizzati  per  la   memorizzazione  delle  informazioni  di  sistema     master     resource     model     tempdb     distribution     msdb   Dr.  Paolo  Casoto,  Ph.D,  2012   28  
  29. 29.   Mantiene  all’interno  tutte  le  informazioni   relative  a:     Configurazione  del  DMS     Configurazione  delle  policy  di  accesso  da  parte   degli  utenti   Cosa  significa  ?  Lo   scopriremo  insieme     Informazioni  sui  linked  server       Tutti  i  riferimenti  ai  DB  creati  dagli  utenti    E  se  manca  il  file  del  db  master?     E’  triste  da  ammettere  ma  …  SQL  Server  non   funziona   Dr.  Paolo  Casoto,  Ph.D,  2012   29  
  30. 30.   Contiene  al  suo  interno  tutte  le  risorse  di   sistema  condivise  da  tutti  gli  altri  DB     SP  e  viste  di  sistema    Non  è  visibile  in  alcun  modo,  ne  mediante   SSMS  ne  mediante  SP  di  sistema    Aggiornando  il  file  associato  ad  db  è  possibile   aggiornare  tutti  gli  oggetti  di  sistema     E  farne  il  backup…   Dr.  Paolo  Casoto,  Ph.D,  2012   30  
  31. 31.   Il  database  model  rappresenta  il  modello  di   database  che  è  replicato  per  ciascun  database   utente     Definisce  il  cosiddetto  Database  Catalog,  l’insieme   degli  oggetti  comuni  a  tutti  i  DB     Aggiungendo  ad  esempio  una  tabella  al  modello,  essa   sarà  disponibile  a  tutti  i  nuovi  db  creati    Il  database  msdb  mantiene  traccia  di  tutte  le   informazioni  generate  dai  servizi  di  gestione  del   Database  Engine     E.g.:  SQL  Server  Agent  per  la  pianificazione  di  task   Dr.  Paolo  Casoto,  Ph.D,  2012   31  
  32. 32.   Il  database  distribution  è  utilizzato  per   memorizzare  tutte  le  informazioni  necessarie  al   processo  di  replicazione  delle  basi  dati  di  un   Database  Engine.    Il  database  tempdb  è  un  database  temporaneo   utilizzato  per  tutte  le  operazioni  che  richiedono   l’utilizzo  di  strutture  dati  temporanee     Rigenerato  a  ciascun  riavvio  del  servizio     Utilizzabile  sia  dalle  operazioni  utente  sia  dalle   operazioni  del  servizio  SQL  Server  stesso   Dr.  Paolo  Casoto,  Ph.D,  2012   32  
  33. 33. IMPORTANTE    Anche  ai  db  di  sistema  deve  essere  riservato   un  trattamento  speciale  in  fase  di  backup     Esattamente  come  per  i  db  applicativi     Dopotutto  se  si  rompe  il  db  master…    Non  è  possibile,  naturalmente,  fare  il  backup  di   resource  e  tempdb     In  realtà  di  resource  solo  a  livello  di  file  !!!    Abbiate  cura  dei  db  di  sistema,  in  particolare  di   msdb  e  distribution  che  possono  crescere  in   maniera  significativa  nel  tempo   Dr.  Paolo  Casoto,  Ph.D,  2012   33  
  34. 34.   Tabelle  utilizzate  per  la  memorizzazione  dei   meta-­‐dati  relativi  al  Database  Engine  ed  ai  suoi   servizi    In  molti  casi  nascoste  all’interno  del  DB  resource    Microsoft  ne  disincentiva  l’uso,  tanto  da  ridurne   il  numero  nel  corso  dell’evoluzione  del  prodotto     Le  tabelle  di  sistema  un  tempo  disponibili  possono   essere  interrogate  mediante  una  vista  di  retro-­‐ compatibilità  che  ne  simula  l’esistenza     Utilizzate  solo  nel  caso  di  applicazioni  che  hanno   necessità  di  accedere  ai  meta-­‐dati  del  Database   Engine   Provate  con  il  database   msdb…   Dr.  Paolo  Casoto,  Ph.D,  2012   34  
  35. 35.   Insieme  di  viste  finalizzate  all’accesso  alle   diverse  tipologie  di  meta-­‐dati  che   Oltre  un   centinaio…   caratterizzano  il  Database  Engine    Suddivise  in:     Viste  di  retro-­‐compatibilità:  utilizzate  per  la   compatibilità  con  sistemi  legacy  basati  su   precedenti  versioni  di  SQL  Server     Viste  di  catalogo:  utilizzate  per  l’accesso  vero  a   proprio  a  tutti  gli  aspetti  di  SQL  Server   ▪  E.g.:Sicurezza,  servizi,  oggetti,  dimensioni   Dr.  Paolo  Casoto,  Ph.D,  2012   35  
  36. 36. ▪  Un  esempio  di  catalogo:  sys.master_files  per  l’accesso   alle  informazioni  relative  ai  file  principali  utilizzati  dai  db   presenti  all’interno  del  Database  Engine    Viste  dello  schema  delle  informazioni:  viste   compatibili  con  SQL  92  per  l’accesso  a  tutte  le   informazioni  relative  allo  schema  dei  dati  per   ciascuna  tabella  di  ciascun  db   ▪  Chiavi   ▪  Chiavi  esterne  e  vincoli   ▪  Tipi  delle  colonne   ▪  Domini   Dr.  Paolo  Casoto,  Ph.D,  2012   36  
  37. 37.   Viste  dinamiche  di  gestione  (DMV):  utilizzate  per   l’accesso  alle  informazioni  relative  allo  stato  del   server  SQL   ▪  E.g.:  stato  della  sicurezza,  percentuale  di  indicizzazione   FULL-­‐TEXT,  performance   ▪  E’  possibile  utilizzare  le  DMV  anche  per  accedere  ad   informazioni  aggregate,  ad  esempio  nel  caso  del   numero  di  esecuzioni  di  una  specifica  stored  procedure   ▪  Novità  introdotta  in  SQL  Server  2005  ed  estesa  nelle   versioni  successive.   Dr.  Paolo  Casoto,  Ph.D,  2012   37  
  38. 38.   Presenti  all’interno  dello  schema  sys  sono   caratterizzate  dal  prefisso  sp.    Utilizzate  in  modo  significativo  dai  DBA   nell’ambito  SQL  Server,  consentono  di  eseguire   interrogazioni  complesse  sulle  tabelle  e  sulle   viste  di  sistema     Strumento  necessario  nella  cassetta  degli  attrezzi  di   un  DBA    Oltre  1.000,  in  grado  di  descrivere  le  diverse  aree   funzionali  del  db  engine.     E.g.:  sp_who:  lista  dei  processi  attualmente  connessi   quale  istanza  di  SQL  Server   Dr.  Paolo  Casoto,  Ph.D,  2012   38  
  39. 39. Insieme   delle  SP   associate  al   Esecuzione   db  master   della  SP   sys.sp_who  Dr.  Paolo  Casoto,  Ph.D,  2012   39  
  40. 40. Dr.  Paolo  Casoto,  Ph.D,  2012   40  
  41. 41.   Per  comprendere  al  meglio  la  gestione  della   sicurezza  in  SQL  Server  2008  R2  è  necessario   definire  alcuni  concetti:     Principali  (principals):  utenti  ai  quali  si  applicano  le   politiche  di  gestione  della  sicurezza   ▪  Utenti  del  db,  utenti  SQL,  utenti  Windows,  et  al.     Oggetti  (securables):  risorse  soggette  al  controllo  di   accesso  da  parte  degli  utenti     Permessi  (permissions):  definizione  di  cosa  un  utente   può  fare  su  un  oggetto  soggetto  a  gestione  della   sicurezza.   Dr.  Paolo  Casoto,  Ph.D,  2012   41  
  42. 42.   Principali  ed  oggetti  sono,  per  loro  natura,   gerarchici     Utenti  e  gruppi     Oggetti  o  insiemi  di  oggetti    Grazie  al  modello  principale  –  oggetto  –   permesso  possono  essere  generate  complesse   gerarchie  di  gestione  della  sicurezza  e   dell’accesso  agli  oggetti     In  modo  abbastanza  simile  a  quanto  già  avviene,  ad   esempio,  in  fase  di  amministrazione  di  un  sistema   Windows.   Dr.  Paolo  Casoto,  Ph.D,  2012   42  
  43. 43.   Il  processo  di  autenticazione  è  il  primo  livello  della   procedura  di  accesso  sicuro  ai  dati     Validazione  delle  credenziali  di  accesso  dell’utente  rispetto   al  server   Modalità     Implementata  in  due  modalità  distinte:     consigliata   ▪  Autenticazione  di  Windows:  utilizza  le  strutture  dati  già  presenti   all’interno  del  sistema  operativo  per  definire  utenti    e  gruppi  che   possono  accedere  al  db  engine   ▪  Consente  di  evitare  il  proliferare  di  password,  procedure  di  aggiunta   o  rimozione  di  utenti,  et  al.   ▪  L’utente  accede  con  le  credenziali  proprie  di  accesso  all’ambiente  Windows   ▪  Se  rimuovo  un  utente  autorizzato  da  Windows  o  ne  modifico  i  gruppi  di   appartenenza,  l’utente  non  potrà  più  accedere  al  db  senza  alcun  bisogno  di   modificare  informazioni  a  livello  del  db  engine   Dr.  Paolo  Casoto,  Ph.D,  2012   43  
  44. 44. ▪  Autenticazione  mista:  consente  di  accedere  al  sistema  sia  mediante  gli   account  Windows  sia  mediante  uno  strumento  di  login  incluso   all’interno  di  SQL  Server.   ▪  La  gestione  dei  login  SQL  è  del  tutto  indipendente  dalla  gestione  dei  login  a  livello   di  Windows   ▪  Spesso  si  utilizzano  entrambe  le  modalità      Sebbene  sia  consigliabile  optare  per  l’autenticazione   Windows,  a  volte  può  rivelarsi  utile  adottare   l’autenticazione  mista     E.g.:  definire  a  livello  di  login  SQL  le  credenziali  per  l’accesso  da   parte  di  un  fornitore  esterno,  non  incluso  fra  gli  utenti  di   Windows.     E.g.:  assenza  all’interno  di  una  infrastruttura  media  o  grande  si   un  sistema  Active  Directory       Da  selezionare  in  fase  di   installazione  ma  modificabile   Dr.  Paolo  Casoto,  Ph.D,  2012   44  
  45. 45.   I  principali  sono  strutture  gerarchiche,  che   consentono  di  identificare  il  titolare  di  un   permesso  rispetto  ad  un  oggetto.    Ciascun  principale  ha  un  suo  id  univoco  che  lo   caratterizza    Possono  essere  composti  da  utenti,  gruppi  e   processi     A  livello  Windows  login  e  gruppi     A  livello  SQL  Server  utenti  e  ruoli     A  livello  database  utenti,  ruoli  utente  e  ruoli   applicazione   Dr.  Paolo  Casoto,  Ph.D,  2012   45  
  46. 46.   Ad  ogni  principale  che  ha  accesso  ad  una   istanza  SQL  Server  deve  essere  associato  un   login     Utenti  o  gruppi  Windows,  utenti  SQL  Server   (questi  ultimi  a  loro  volta  chiamati,  con  poca   chiarezza,  SQL  Server  Login  )    Memorizzati  all’interno  del  database  master,   consentono  di  definire  permessi  per  l’accesso   alle  risorse  a  livello  di  server   Vedremo  in     No  ad  una  risorsa  di  un  singolo  database   seguito   Dr.  Paolo  Casoto,  Ph.D,  2012   46  
  47. 47. Utilizzo  una  vista  di  sistema  per   accedere  alla  lista  dei  principali   presenti  all’interno  del  mio  db   engine  Dr.  Paolo  Casoto,  Ph.D,  2012   47  
  48. 48.   In  fase  di  installazione  due  login  sono   generati  in  modo  automatico  dal  sistema:     per  l’utente  sa,  definito  come  utente  SQL  Server   (con  password),  finalizzato  all’amministrazione   del  sistema  e  non  modificabile     per  NT  AUTHORITY/SYSTEM:  account  locale   assegnato  al  sistema  Windows  ove  il  server  è  in   esecuzione.  Ha  funzionalità  di  amministratore  ma   può  essere  eventualmente  rimosso   Dr.  Paolo  Casoto,  Ph.D,  2012   48  
  49. 49.   Modello  flessibile  per  la  gestione  del  processo   di  autenticazione     Del  tutto  analoghi  al  concetto  di  gruppi  in   ambiente  Windows  –  Active  Directory     Tutti  gli  utenti  che  appartengono  ad  un  ruolo  ne   ereditano  i  permessi    I  ruoli  consentono  di  non  dover  più  gestire  la   sicurezza  a  livello  dei  singoli  utenti     Gestiamo  la  sicurezza  a  livello  di  ruolo  ed   associamo  gli  utenti   Dr.  Paolo  Casoto,  Ph.D,  2012   49  
  50. 50.   Vi  sono  3  tipologie  di  ruoli  utente  in  SQL   Server:   1.  Ruoli  fissi  a  livello  di  server  e  di  db:  creati   automaticamente  dal  sistema  a  livello  degli   oggetti  del  server  e  dei  singoli  db   2.  Ruoli  definiti  dall’utente  a  livello  di  singolo   database.   3.  Ruoli  definiti  a  livello  di  applicazione.   Dr.  Paolo  Casoto,  Ph.D,  2012   50  
  51. 51.   Ruoli  prefissati  per  default  ed  orientati  alla   gestione  degli  utenti  a  livello  di  server     Descrivono  i  ruoli  più  frequenti  per  gli  utenti  del   database     E.g.:     Gestione  delle  funzioni  di   ▪  bulkadmin   amministrazione  del  DB   ▪  dbcreator   ▪  public   Permessi  associati  a  tutti  i   ▪  sysadmin   login  del  server    unico   ▪  …   ruoli  fisso  modificabile     Più  ruoli  possono  essere  associati  al  medesimo  login   Dr.  Paolo  Casoto,  Ph.D,  2012   51  
  52. 52. Ruoli  che  non  possono  essere  modificati  dall’amministratore.   Dr.  Paolo  Casoto,  Ph.D,  2012   52  
  53. 53.   Ruoli  prefissati  per  default  ed  orientati  alla   gestione  degli  utenti  a  livello  del  singolo   database   Dr.  Paolo  Casoto,  Ph.D,  2012   53  
  54. 54.   Versione  personalizzata  dei  ruoli  prefissati,   modificabile  dagli  utenti  al  fine  di  generare  un   ruolo  ad  hoc     Controllo  con  una  maggiore  granularità  dei   permessi.    In  generale  da  utilizzare  solo  se  necessari   poiché,  come  ho  già  detto  rendono  ancora   più  complessa  la  manutenzione     E  l’aggiornamento…   Dr.  Paolo  Casoto,  Ph.D,  2012   54  
  55. 55.   Ruoli  che  non  sono  associati  ad  alcun  login     Invece  di  aggiungere  al  ruolo  un  insieme  di  utenti   definisco  una  password     A  quale  scopo  definire  questa  tipologia  di  ruoli  ?   ▪  Per  consentire  l’accesso  mediante  la  definizione  di   specifiche  applicazioni   ▪  Solo  l’applicazione  che  include  al  suo  interno  una   connessione  mediante  la  password  associata  al  ruolo   può  accedere  ai  permessi  per  essa  definiti     Indipendente  dallo  specifico  utente  del  client   Dr.  Paolo  Casoto,  Ph.D,  2012   55  
  56. 56.   Principale  che  può  interagire,  in  accordo  con   gli  specifici  permessi,  con  a    livello  di  singolo   database,  con  tutte  le  risorse  che  lo   compongono.      Collegano  un  login  ad  uno  specifico  database     Necessari  per  l’accesso  al  db     Un  utente  a  livello  di  database  può  essere   associato  a  più  login  o  a  login  di  differente   tipologia     Attenzione  alla  copia   ▪  E.g.:  login  associati  ad  utenti  o  a  gruppi   del  DB  fra  server   differenti  !!!!   Dr.  Paolo  Casoto,  Ph.D,  2012   56  
  57. 57.   L’utente  dbo  è  il  proprietario  del  database  e   non  può  essere  cancellato.     Tutti  i  membri  del  ruolo  server  sysadmin  sono   mappati,  per  ciascun  database,  all’utente  dbo     Tutti  gli  oggetti  dell’utente  dbo  non  necessitano   dell’utilizzo  dello  schema     ▪  In  fase  di  identificazione  di  un  oggetto  privo  di  schema,  il   sistema  verifica  in  prima  istanza  fra  gli  oggetti  con   schema  uguale  al  nome  utente  e  successivamente  fra  gli   oggetti  di  dbo   ▪  Vedremo  fra  qualche  slide  il  significato  di  queste  frasi   Dr.  Paolo  Casoto,  Ph.D,  2012   57  
  58. 58.   L’utente  guest  è  utilizzato  per  fungere,  in   ciascun  database,  da  utente  di  accesso     Nel  caso  in  cui  al  login  non  sia  associato  alcun  utente   del  database     Per  default  limitato,  da  utilizzarsi  anche  in  questo   caso,  solo  con  estrema  attenzione  alle  criticità  legate   alla  sicurezza  !!!    Gli  utenti  INFORMATION_SCHEMA  e  sys   consentono  l’accesso  ai  metadati  del  database     Sono  creati  automaticamente  e  non  possono  essere   rimossi.   Nel  99%  dei  casi  non  li   modificherete  mai   Dr.  Paolo  Casoto,  Ph.D,  2012   58  
  59. 59.   Uno  schema  è  definito  come  una  raccolta  di   oggetti  del  database  posseduti  da  un  utente   che  costituiscono  un  spazio  dei  nomi  unico     Uno  spazio  dei  nomi  (o  namespace)  è  un  insieme   in  cui  ciascun  oggetto  ha  un  nome  UNIVOCO   ▪  Il  nome  dell’oggetto  è  CHIAVE  rispetto  al  namespace     Ogni  utente  può  essere  associato  ad  uno  schema   con  il  suo  stesso  nome  ovvero  ad  uno  schema  di   default   ▪  E.g.:  utenti  associati  per  default  allo  schema  dbo   Dr.  Paolo  Casoto,  Ph.D,  2012   59  
  60. 60.   Alla  creazione  di  un  nuovo  oggetto  del   database  da  parte  di  un  utente,  lo  schema   sarà  utilizzato  per  definirne  il  nome     E.g.:  tabella  database.paolo.ordineproduzione    Nelle  precedenti  versioni  di  SQL  Server  non   era  presente  una  netta  separazione  fra   schemi  ed  utenti     Ciascun  utente,  per  default,  era  associato  solo  allo   schema  con  il  proprio  username.   Dr.  Paolo  Casoto,  Ph.D,  2012   60  
  61. 61.   Collegano  gli  oggetti  contenuti  all’interno  di   SQL  Server  (che  abbiamo  definiti  come   securable)  ai  principali     Definiscono  cosa,  a  diverso  livello,  può  fare  un   principale     ▪  Siano  essi  login,  ruoli  a  diversi  livelli,  utenti  a  livello  del   database.     Tre  valori:  GRANT,  DENY,  REVOKE   ▪  Revoke  elimina  ogni  permesso  definito  su  un  oggetto   per  un  principale    Stato  indeterminato     Dr.  Paolo  Casoto,  Ph.D,  2012   61  
  62. 62.   I  permessi  agiscono  sugli  oggetti  a  livello   gerarchico     Permessi  a  livello  di  server     Permessi  a  livello  di  database     Permessi  a  livello  di  schema      Se  imposto  una  regola  più  restrittiva  a  livello   di  schema,  tale  regola  sovrascrive  tutte  le   regole  per  lo  stesso  oggetto  definite  a  livello   di  server.   Dr.  Paolo  Casoto,  Ph.D,  2012   62  
  63. 63. SQL  Login  o  Windows  Login  Dr.  Paolo  Casoto,  Ph.D,  2012   63  
  64. 64. Gestione   password  e   politica  di  rinnovo   Mapping:  per  ora   li  ignoreremo   Database  e  lingua   di  default.  Se   nessuna  lingua  è   specificata  il   valore  DEFAULT   assume  il  valore   della  lingua  del  Dr.  Paolo  Casoto,  Ph.D,  2012   server.   64  
  65. 65. Consente  la   definizione  dei   ruoli  server  (fixed   server  roles)   associati  al  login.    Dr.  Paolo  Casoto,  Ph.D,  2012   65  
  66. 66. Consente  la   definizione  degli   utenti  associati  al   login  per  ciascun   database.  Dr.  Paolo  Casoto,  Ph.D,  2012   66  
  67. 67. Definizione  dello   schema  di  default   e  dei  ruoli  a  livello   di  database  Dr.  Paolo  Casoto,  Ph.D,  2012   67  
  68. 68. Definizione  dei   permessi   dell’utente   rispetto  a  specifici   oggetti  del  db  Dr.  Paolo  Casoto,  Ph.D,  2012   68  
  69. 69. Dr.  Paolo  Casoto,  Ph.D,  2012   69  
  70. 70. Permessi  associati   ad  un  login  Dr.  Paolo  Casoto,  Ph.D,  2012   70  
  71. 71. Permessi  associati   ad  un  database   In  questo  caso  le   autorizzazioni   sono  ereditate  dal   database  dal   livello  del  server  Dr.  Paolo  Casoto,  Ph.D,  2012   71  
  72. 72. Permessi  associati   ad  uno  schema   Anche  in  questo   caso  le   autorizzazioni   sono  ereditate  dal   database  dal   livello  del  server  Dr.  Paolo  Casoto,  Ph.D,  2012   72  
  73. 73. Dr.  Paolo  Casoto,  Ph.D,  2012   73  
  74. 74.   In  SQL  Server  2008  R2  ciascun  db  è   rappresentato  da  un  insieme  di  almeno  due  file:     Il  file  dei  dati     Il  file  di  log  delle  transazioni     Ulteriori  file  possono  essere  definiti  come  opzionali    Collocati  all’interno  di  una  cartella  del  filesystem   la  cui  locazione  può  essere  definita  in  fase  di   creazione  del  db  e  successivamente  aggiornata.     Mediante  le  viste  di  sistema  è  possibile  conscere  i   dettagli  relativi  alla  memorizzazione  fisica  di  ciascun   db   Dr.  Paolo  Casoto,  Ph.D,  2012   74  
  75. 75.   Per  ciascun  file  utilizzato  per  la  rappresentazione   di  un  database  è  possibile  definire  le  seguenti   proprietà:     Nome  logico  e  fisico;     Dimensione  iniziale  del  file   ▪  Nel  caso  del  file  dei  dati,  dimensione  necessaria  per   mantenere  i  contenuti  degli  oggetti  creati  utilizzando  il   database  model  come  template     Dimensione  massima  del  file     Intervalli  di  espansione  del  file   ▪  Quanto  il  file  può  crescere  in  caso  di  necessità,  in  termini   assoluti  o  percentuali.   L’espansione  automatica  di  un  file  può  essere  molto   Dr.  Paolo  Casoto,  Ph.D,  2012   incidere  significativamente  TRADE  OFF     onerosa  ed   75  
  76. 76.   Un  filegroup  è  un  insieme  logico  di  file  che   compongono  il  database     Concetto  simile  al  concetto  di  directory    E’  possibile  assegnare  un  oggetto  del  database   ad  uno  specifico  filegroup  in  modo  del  tutto   indipendente  dai  file  sottostanti     Assegno  una  tabella  critica  ad  un  filegroup  composto   da  4  file  dati.     ▪  Le  query  alla  tabella  saranno  eseguite  sui  4  file  con   incremento  delle  performance  nel  caso  di  I/O  su  device   differenti   ▪  Anche  i  dati  relativi  alla  tabella  saranno  ripartiti  fra  i  file  che   appartengono  al  filegroup   Dr.  Paolo  Casoto,  Ph.D,  2012   76  
  77. 77.   Ciascun  file  utilizzato  per  la  rappresentazione   di  un  database  può  essere  definito  come:     File  dati  primario     File  dati  secondario     File  di  log  delle  transazioni     File  FILESTREAM   Questi  ultimi     File  dei  dati  testuali   introdotti  in  SQL   Server  2008   Dr.  Paolo  Casoto,  Ph.D,  2012   77  
  78. 78.   Ogni  database  deve  avere  uno  (ed  un  solo)  file  primario  dei   dati    E’  il  primo  file  ad  essere  letto  da  SQL  Server  quando  si   accede  ad  un  database    Ha  estensione  mdf  ed  appartiene  al  gruppo  di  file  di   default  del  database.    Generalmente  un  solo  file  per  la  memorizzazione  dei  dati  è   sufficiente     Posso  gestirne  l’accesso  ed  il  backup  mediante  una  partizione   RAID  logica  o  fisica…     …ma  se  volessi  gestire  la  distribuzione  dei  dati  del  database  su   un  array  di  dischi  con  una  maggiore  precisione,  ad  esempio  a   livello  di  singole  tabelle  ?     Devo  necessariamente  creare  file  dati  secondari.   Dr.  Paolo  Casoto,  Ph.D,  2012   78  
  79. 79.   Un  database  può  avere  un  numero  elevato   (2^15)  di  file  dati  secondari     Con  estensione  ndf,  possono  essere  collocati   all’interno  del  filegroup  di  default  del  database  o  in  un   filegroup  definito  ad  hoc.    Ma  quando  sono  necessari  ?     Backup  parziale:  salvo  solo  le  tabelle  che  l’utente  può   modificare…vedremo  in  seguito     Ripartire  il  database  (ed  il  carico  di  I/O)  su  più  dischi     Rendere  più  agevole  la  procedura  di  ripristino  di   database  di  dimensione  significativa,  suddividendoli   su  più  dischi   Dr.  Paolo  Casoto,  Ph.D,  2012   79  
  80. 80.   Alcuni  consigli:     Su  database  di  dimensione  limitata  non   preoccupatevene     Su  database  le  cui  tabelle  hanno  una  dimensionalità   ed  un  utilizzo  equilibrato  non  preoccupatevene   ▪  Nel  caso  in  cui  nessuna  tabella  sia  utilizzata  in  modalità  quasi   esclusiva  rispetto  alle  altre     Se  avete  a  disposizione  solo  un  disco  …  non   preoccupatevene.   ▪  Ripartire  il  db  su  più  file  all’interno  dello  stesso  disco  non   migliora  le  performance,  anzi,  potrebbe  degradarle.    In  generale  il  tutto  dipende  da  come  è   caratterizzata  la  vostra  infrastruttura  HW  e  SW   Dr.  Paolo  Casoto,  Ph.D,  2012   80  
  81. 81.   File  di  dimensione  massima  di  32TB  finalizzati   alla  memorizzazione  delle  transazioni  che   possono  aver  luogo  all’interno  del  database     Anche  più  di  un  file  di  log  per  database    Non  possono  essere  parte  di  un  filegroup  e   non  possono  ospitare  informazioni  differenti   dal  log  delle  transazioni.   Dr.  Paolo  Casoto,  Ph.D,  2012   81  
  82. 82.   Integrazione  di  SQL  Server  e  del  filesystem   NTFS  finalizzata  alla  memorizzazione  di   informazione  non  strutturata  (e.g.:  immagini)   sotto  forma  di  file     Trasformazione  delle  query  T-­‐SQL  in  istruzioni  per  il   filesystem  NTFS    Non  entriamo  nel  dettaglio,  sebbene  sia  molto   utile  per  la  memorizzazione  di  molte  tipologie  di   informazioni  in  un  database  aziendale     E.g.:  realizzazione  di  un  Document  management   System  (DMS)   Dr.  Paolo  Casoto,  Ph.D,  2012   82  
  83. 83.   La  legge  di  Murphy  può  essere  molto   pericolosa  per  gli  amministratori  di  basi  di   dati     “Se  le  cose  possono  andare  male,  sicuramente  lo   faranno”    E’  necessario  definire  un  piano  di  emergenza   nel  caso  in  cui  sia  necessario  recuperare  i  dati   e  ripristinare  il  sistema     Adeguata  politica  di  backup  e  restore   Dr.  Paolo  Casoto,  Ph.D,  2012   83  
  84. 84.   Il  piano  di  emergenza  deve  prevedere  tutte  (o   quasi)  le  possibili  cause  di  perdita  dei  dati     Ed  allo  stesso  tempo  di  sospensione  delle  funzionalità   del  server.    Verificare  esigenze  e  criticità  dell’ambito  di   utilizzo  del  DBMS  rispondendo  alle  seguenti   domande:     Quale  perdita  di  dati  è  ritenuta  accettabile  ?  Ore,   giorni,  mesi?   ▪  E.g.:  gestionale  probabilmente  giorni,  in  un  software  di   gestione  della  produzione  probabilmente  minuti  o  al   massimo  ore.   Dr.  Paolo  Casoto,  Ph.D,  2012   84  
  85. 85.   Qual  è  la  funzione  del  DBMS  ?     ▪  OLAP,  OLTP,  Data  Warehouse,  et  al.    Qual  è  l’intervallo  di  aggiornamento  dei  dati   all’interno  della  base  di  dati  ?     ▪  Dati  con  aggiornamento  poco  frequenti  (e.g.:  CMS  web)   o  con  aggiornamenti  frequenti  (e.g.:  rilevamento  dati  in   tempo  reale).    Qual  è  il  tempo  di  downtime  accettabile  ?    Che  dimensioni  hanno  i  database  per  i  quali  è   necessario  effettuare  il  backup  e  quali  media  sono   a  disposizione  del  piano  di  backup  ?   Dr.  Paolo  Casoto,  Ph.D,  2012   85  
  86. 86.   Ed  ultima,  ma  non  per  importanza  …       quale  budget  avete  a  disposizione  per   implementare  la  politica  di  backup  e  restore  ?    L’insieme  delle  risposte  alle  domande   precedenti  deve  consentire  al  responsabile   del  DBMS  di  definire  un  piano  di  backup  e   ripristino  dei  dati     Che  integri  tutti  i  bisogni  dell’infrastruttura  …     …  con  i  mezzi  ed  i  costi  a  disposizione.   Dr.  Paolo  Casoto,  Ph.D,  2012   86  
  87. 87.   SQL  Server  2008  R2  supporta  molteplici   tipologie  di  backup:     Backup  completo     Backup  differenziale     Backup  parziale     Backup  parziale  differenziale     Backup  dei  file  (e  dei  gruppi  di  file)     Backup  dei  log  della  transazioni     Backup  in  modalità  copia   Dr.  Paolo  Casoto,  Ph.D,  2012   87  
  88. 88.   Salvataggio  dello  stato  di  un  intero  database  in  un   dato  istante  di  tempo     Consente  il  recupero  completo  del  db     E’  transazionalmente  completo  e  mantiene  al  suo  interno   non  solo  i  dati  ma  anche  la  struttura  del  database  stesso    In  SQL  Server  2008  R2  non  è  necessario  interrompere   l’operatività  del  DBMS  in  fase  di  backup     Tutte  le  transazioni  eseguite  durante  la  copia  sono   accodate  alla  copia  stessa   ▪  Identificazione  del  Log  Sequence  Number  (LSN)  associato   all’ultima  transazione  eseguita  prima  dell’avvio  del  processo  di   backup   Dr.  Paolo  Casoto,  Ph.D,  2012   88  
  89. 89.   Generalmente  il  backup  completo  si  utilizza   solo  nel  caso  di  basi  di  dati  di  dimensionalità   ridotta.     In  generale  si  utilizza  in  congiunzione  con  altre   tipologie  di  backup     Costituisce  la  prima  sorgente  dati  da  ripristinare  in   caso  di  necessità   ▪  Ad  esempio  mediante  integrazione  con  il  backup  del  log   delle  transazioni   Dr.  Paolo  Casoto,  Ph.D,  2012   89  
  90. 90.   Cattura  tutte  le  differenze  rispetto  all’ultimo   backup  completo       Che  prende  il  nome  di  base  differenziale.    Si  analizzano  tutti  gli  extent  (insiemi  di  8   pagine  da  8  KB,  vi  ricordate  ???)  e  si   identificano    eventuali  modifiche  rispetto  al   backup  completo     Solo  gli  extent  modificati  sono  memorizzati   all’interno  del  backup  differenziale   Dr.  Paolo  Casoto,  Ph.D,  2012   90  
  91. 91.   Usato  in  congiunzione  con  il  backup   completo  dei  dati,  consente  l’esecuzione  di   backup  più  veloci  e  di  dimensionalità  ridotta    Ottimale  nel  caso  in  cui  nell’intervallo  di   backup  siano  presenti  poche  modifiche   rispetto  al  backup  completo     O  in  generale  modifiche  raccolte  in  un  cluster  di   pagine  prossime  fra  loro.   Dr.  Paolo  Casoto,  Ph.D,  2012   91  
  92. 92.   Consentono  il  backup  dei  soli  dati  del   database  modificabili     Non  si  procede  al  backup  dei  dati  in  sola  lettura   che  sono  presenti  all’interno  della  base  dati   ▪  Che  dovranno  comunque  essere  soggetti  a  backup,  ma   non  periodico  nel  tempo    Sia  a  livello  completo  sia  a  livello  differenziale     Memorizzo  solo  gli  extent  modificati  all’interno   delle  aree  non  in  sola  lettura  del  database   Dr.  Paolo  Casoto,  Ph.D,  2012   92  
  93. 93.   Backup  mirati  nel  caso  di  database  composti  da  più   filegroup.     Tutti  i  file  presenti  all’interno  del  filegroup  sono   memorizzati    Utilizzati  spesso  nel  caso  di  database  più  ampi   dimensionalmente,  dove  lavorare  a  livello  di  singolo   backup  è  troppo  oneroso  in  termini  di  tempo.    Al  fine  di  ripristinare  questo  tipo  di  database  è   necessario  disporre  di  tutti  i  file  salvati  in  uno  specifico   istante  di  tempo.     Per  poter  gestire  il  backup  con  la  certezza  di  non  incorrere   nella  perdita  di  dati  è  necessario  lavorare  mantenendo   anche  il  backup  del  log  delle  transazioni.   Dr.  Paolo  Casoto,  Ph.D,  2012   93  
  94. 94.   Copia  completa  del  db  che  non  incide  sulla   catena  del  ripristino  del  db  stesso     E.g.:  il  backup  ottenuto  non  diventa  una  base   differenziale  del  db.     In  generale  si  utilizza  per  disporre  di  una  copia   stand-­‐alone  del  database.    Il  backup  del  file  di  log  delle  transazioni  è   utilizzato  in  molteplici  tipologie  di  ripristino   dei  dati,  come  scopriremo  nelle  prossime   slide.   Dr.  Paolo  Casoto,  Ph.D,  2012   94  
  95. 95.   SQL  Server  2008  R2  supporta  3  modelli  di   ripristino  dei  dati  in  caso  di   malfunzionamento:     Ripristino  completo     Ripristino  BULK  LOGGED     Ripristino  semplice    La  modalità  di  ripristino  è  una  caratteristica   del  singolo  database     Politiche  differenti  possono  essere  applicate  a   database  differenti.   Dr.  Paolo  Casoto,  Ph.D,  2012   95  
  96. 96.   Modalità  più  sicura  per  il  corretto  ripristino   dei  dati     Tutte  le  operazioni  eseguite  sul  db  sono  riportate   anche  all’interno  del  file  delle  transazioni   associato  al  db  stesso   ▪  Inserimenti,  cancellazioni,  aggiornamenti,  inserimenti  di   massa  (BULK)  et  al.     In  caso  di  ripristino  ho  la  possibilità  di  ripristinare  il   db  utilizzando  un  backup  aggiornabile  grazie  al   log  delle  transazioni  fino  all’ultima  transazione   correttamente  completata.   Dr.  Paolo  Casoto,  Ph.D,  2012   96  
  97. 97.   Attenzione:  il  file  di  log  delle  transazioni  può   crescere  in  dimensionalità  molto  velocemente     Soprattutto  in  ambienti  soggetti  a  molteplici   transazioni,  quale  un  ambiente  di  raccolta  dei  dati   della  produzione  sul  campo.     Aggiunge  un  overhead  al  DBMS,  che  deve   memorizzare  copia  delle  operazioni  di  modifica  che   avvengono    Gestire  con  efficacia  il  backup  del  log  delle   transazioni,  per  evitarne  a  perdita  in  caso,  ad   esempio,  di  un  malfunzionamento  del  device   dove  è  memorizzato   Dr.  Paolo  Casoto,  Ph.D,  2012   97  
  98. 98.   Variante  del  ripristino  completo     Non  memorizza  sul  log  delle  transazioni,  in  caso  di   operazioni  di  immissione  di  massa,  tutte  le  righe     Memorizza  i  riferimenti  agli  extent  modificati     Il  file  di  log  delle  transazioni  riduce  le  sue  dimensioni   ▪  Anche  di  molti  ordini  di  grandezza    Ma…aumenta  la  dimensione  del  backup  del  file   di  log  delle  transazioni     Poiché  devo  includere  tutte  le  informazioni  relative   agli  extent  modificati  dalla  riga  riportata  all’interno   del  log  delle  transazioni   ▪  Ed  ogni  extent  sono  64  KB…   Dr.  Paolo  Casoto,  Ph.D,  2012   98  
  99. 99.   La  modalità  presenta  un  altro  problema     Posso  ripristinare  tutte  le  operazioni  che  sono  presenti   nel  backup  del  file  di  log  delle  transazioni   ▪  Non  nel  file  delle  transazioni  stesso     Se  eseguo  una  modifica  di  tipo  bulk  al  db,  la  scrivo  nel   file  di  log  delle  transazioni  ma  nel  frattempo  non  ho   eseguito  il  backup  del  file  di  log  delle  transazioni… perdo  la  modifica    Per  le  modifiche  non  BULK  (creazione,   aggiornamento  e  cancellazione,  opera  in  modo   del  tutto  analogo  al  ripristino  completo).   Dr.  Paolo  Casoto,  Ph.D,  2012   99  
  100. 100.   Meno  sicuro,  sebbene  più  semplice  da  gestire   a  livello  di  DBA     Il  file  di  log  delle  transazioni  è  troncato  a  specifici   intervalli  di  tempo  detti  checkpoint    Il  file  di  log  delle  transazioni  potrebbe,  quindi,   non  essere  sufficiente  per  garantire  il   ripristino  della  base  di  dati  dall’ultimo  backup     Non  è  una  soluzione  attuabile  per  un  database  in   produzione   Dr.  Paolo  Casoto,  Ph.D,  2012   100  
  101. 101.   Dispositivi  disco     Hard  disk  locali,  hard  disk  di  rete  (SAN),  dischi  allo   stato  solido   ▪  Velocità  ed  affidabilità.    Dispositivi  a  nastro  –  dispositivi  ottici     Utilizzati  storicamente,  hanno  il  vantaggio  di  poter   essere  rimossi  e  conservati  in  un  luogo  sicuro   ▪  Soggetti    a  deterioramento,  con  velocità  limitata  rispetto  ai   dischi.    Dispositivi  di  rete     Eseguo  il  backup  all’interno  di  una  locazione  di  rete   ▪  Che  a  sua  volta  dovrà  necessariamente  essere  un  dispositivo   fisico  delle  tipologie  descritte  in  precedenza.   Dr.  Paolo  Casoto,  Ph.D,  2012   101  

×