Backup/Restore come Initial Snapshot di una replica transazionale

In certi scenari di replica, dove il DB da pubblicare è di grosse dimensioni, potrebbe essere conveniente configurare la/le sottoscrizioni partendo da un Backup\Restore anziché da un Initial Snapshot come prevede la procedure standard.
La creazione dell'Initial Snapshot potrebbe essere molto lunga e consumare molte risorse che in questo modo risparmiamo.

T-SQL e caricamento dati differenziale..... E le performance ?

Immaginiamo questo scenario :
DBTarget è un DB OLAP che contiene una tabella TargetTable ed è utilizzato per effettuare Business Intelligence
DBSource è il DB OLTP che contiene una tabella SourceTable ed è utilizzato dai programmi aziendali di gestione.
Abbiamo la necessità di allineare il contenuto di TargetTable con quello di SourceTable utilizzando T-SQL.

Script Rebuild o Reoganize ?

E' sempre necessario fare la rebuild di un indice o posso farne la reorganize ?
Per dirla in modo estrememente sintetico e semplificato, la Rebuild è molto efficiente  ma pesante , la Reorganize meno efficace ma più leggera...

SQL Saturday : Milano 08-10-2013

L'8 ottobre 2013 presso l'Innovation Campus di Microsoft in Via Lombardia, 2, Milano si terrà il SQL Saturday con sessioni molto interessanti e speaker italiani ed internazionali.

Qui trovate l'agenda.
Qui potete registrarvi.

Ciao

Luca

SQL Server 2014 CTP1 : In-Memory Optimized Tables, No Lock and Latch !!!

Fino all'edizione 2012 il meccanismo di controllo delle transazioni faceva largo uso di Lock e di Latch, con tutti i problemi derivanti alla loro gestione
(Consumo di risorse, low performance, etc.... )
Le In-Memory Optimized Tables introdotte da SQL Server 2014 CTP1 utilizzano un meccanismo di gestione accessi concorrenziali di tipo Optimistic Multiversion,
che consente alle transazioni di essere Lock e Latch Free.