Il modo migliore per reimportare grandi quantità di dati con tempi di inattività minimi

Ho bisogno di importare circa 500.000 record contenenti dati di ricerca IP (riferimento di sola lettura) circa una volta alla settimana (solo tre col int / bigint).

Non voglio davvero preoccuparmi di unire i dati con la tabella esistente, preferirei cancellare il vecchio e reimportare.

Idealmente, le query in esecuzione sui dati continuerebbero a essere eseguite (non ne riceviamo molti di questi ed è accettabile che vengano eseguiti un po 'più lentamente durante l'importazione, ma devono essere attivi 24/7, quindi eseguendo questo " fuori orario "non è un'opzione).

Le cose provate finora

SSIS: ho creato un pacchetto SSIS che tronca la tabella e le importazioni: l'esecuzione richiede circa 30 secondi (troppo a lungo davvero).

Tabella temporanea: l'importazione in una tabella temporanea, il troncamento e la copia attraverso richiedono anche circa 30 secondi.

BCP: Anche l'importazione di massa è piuttosto lenta (per qualche motivo è più lenta di SSIS (anche senza indici da mantenere) - Immagino che abbia a che fare con le transazioni char-> int / bigint: /

Tavolo a specchio? Quindi, al momento, mi chiedo di leggere la tabella attraverso una vista, importare i dati in una tabella speculare e modificare la vista per puntare a questa tabella ... sembra che sarà veloce, ma sembra minuscolo un po 'confuso con me.

Sembra che dovrebbe essere un problema comune, ma non riesco a trovare le pratiche raccomandate: qualsiasi idea sarebbe apprezzata!

Grazie

Una soluzione che ho usato in passato (e che ho consigliato qui e su StackOverflow prima) è quella di creare due schemi aggiuntivi:

CREATE SCHEMA shadow AUTHORIZATION dbo;
CREATE SCHEMA cache  AUTHORIZATION dbo;

Ora crea un mimico della tua tabella nello cacheschema:

CREATE TABLE cache.IPLookup(...columns...);

Ora quando si esegue l'operazione di commutazione:

TRUNCATE TABLE cache.IPLookup;
BULK INSERT cache.IPLookup FROM ...;

-- the nice thing about the above is that it doesn't really
-- matter if it takes one minute or ten - you're not messing
-- with a table that anyone is using, so you aren't going to
-- interfere with active users.


-- this is a metadata operation so extremely fast - it will wait
-- for existing locks to be released, but won't block new locks
-- for very long at all:

BEGIN TRANSACTION;
  ALTER SCHEMA shadow TRANSFER    dbo.IPLookup;
  ALTER SCHEMA dbo    TRANSFER  cache.IPLookup;
COMMIT TRANSACTION;


-- now let's move the shadow table back over to
-- the cache schema so it's ready for next load:

ALTER SCHEMA cache TRANSFER shadow.IPLookup;
TRUNCATE TABLE cache.IPLookup; 

-- truncate is optional - I usually keep the data
-- around for debugging, but that's probably not
-- necessary in this case.

Questo sarà più ingombrante se si hanno chiavi esterne e altre dipendenze (poiché potrebbe essere necessario eliminarle e ricrearle), e ovviamente invalida completamente le statistiche ecc. E questo, a sua volta, può influire sui piani, ma se il la cosa più importante è ottenere dati precisi davanti ai tuoi utenti con una minima interruzione, questo può essere un approccio da considerare.