Ciao,
Ho 3 tabelle che devo prelevare da una istanza di SQL Server Express 2005, farne una copia di sviluppo in locale da me su una istanza di SQL Server Express 2008. Voglio sapere come fare, perché non sono ancora riuscito nonostante vari tentativi. Escludete pure a priori il dump del database intero (sono molti e molti giga e non è fattibile), anche perché il backup va fatto via internet.
Una delle tabelle ha circa 675.000 record, quindi devo ottenere per forza un file di dump che non posso modificare poi a mano, ma deve andare in pasto alla mia macchina pari pari così come è. Se per caso fosse fattibile ottenendo un file con una serie di insert, ho bisogno di sapere come fare a eseguire un file da 700MB di Insert senza doverlo per forza caricare in un editor, e dunque ho bisogno di potere avere un comando da riga di comando di SQL Server del tipo "esegui file X.sql"
Uno dei problemi principali è che tutte le tabelle di questo maledetto DB hanno una colonna di tipo TIMESTAMP che per SQL Server è un campo binario, che indica una specie di identificativo univoco di riga. Se esporto in SQL usando strumenti quali DBVisualizer, questo mi viene esportato come una farfuglia di caratteri esadecimali e fallisce sempre la importazione.
Ho provato a esportare come CSV, come insert SQL, tutte le prove con tutti gli strumenti che ho usato sono fallite miseramente.
Vi prego, datemi una mano prima che spacchi il monitor a testate
Copy table tramite visual studio?
Dalla mia esperienza (sono circa 15 anni che lavoro anche sui database, quasi esclusivamente su sql server -non express, però-), la maniera più efficiente di spostare/copiare un database è il backup/restore. Considera che se i dati contenuti nel db non sono di tipo binario già compresso (per. es. immagini jpeg), puoi effettuare una compressione del backup guadagnando un buon 80% dallo spazio occupato inizialmente, e traferirlo anche via internet in maniera abbastanza indolore splittando in vari pezzi.
Alla peggio, se stiamo parlando di 10 o più giga di roba (già compressi? omg), prepara i files backup sulla macchina sorgente, comprimili con password, fatteli masterizzare da qualcuno che sta li sul posto e fatteli inviare per raccomandata.
Alla peggio, se stiamo parlando di 10 o più giga di roba (già compressi? omg), prepara i files backup sulla macchina sorgente, comprimili con password, fatteli masterizzare da qualcuno che sta li sul posto e fatteli inviare per raccomandata.
Un database è remoto. La soluzione deve essere eseguita in due step: uno sul database remoto (dump) e uno sul database copia (restore)
Il database ha circa 1000 tabelle. Me ne servono 3. Fare il backup è una follia..
1) crea un nuovo database in remoto
2) copiaci le 3 tabelle che ti interessano con export data dal database grande al database nuovo
3) fai il backup del database nuovo (che conterrà solo le 3 tabelle)
4) comprimi il backup del database nuovo
5) ???
6) PROFIT!
2) copiaci le 3 tabelle che ti interessano con export data dal database grande al database nuovo
3) fai il backup del database nuovo (che conterrà solo le 3 tabelle)
4) comprimi il backup del database nuovo
5) ???
6) PROFIT!
Ribadisco.
Connessione al db remoto, connessione al db copia--> copy table.
Profit.
Minokin, così come dici tu i dati non li comprimi.
Per comprimere la trasmissione a livello SSIS dovresti usare un prodotto della RedGate (ottimi) che si chiama SQL HyperBac.
In questo modo i dati ti vengono compressi in maniera trasparente mentre fai il copy table.
Per comprimere la trasmissione a livello SSIS dovresti usare un prodotto della RedGate (ottimi) che si chiama SQL HyperBac.
In questo modo i dati ti vengono compressi in maniera trasparente mentre fai il copy table.
Ecco la mia soluzione
DBVisualizer Personal con licenza di prova da 15 giorni.
Export table come SQL statement, convertendo i campi date time in formato particolare e ignorando i BLOB altrimenti tutti i campi di tipo timestamp faceva cavolate
Ottenuto file da 1.4GB per una tabella (gli altri circa 1/3)
Compresso RAR, ottenuto file da 35MB circa
Trasferimento file via FTP
UnRar sul mio cliente -> 1.4GB
Esecuzione query di insert da 1.4GB con DBVisualizer Personal (4H siccome mi ero scordato di disabilitare gli indici, ma fa lo stesso)
Ripetuto procedimento per le 3 tabelle
Alcuni proprio non avevano capito che non potevo non comprimere i dati
DBVisualizer Personal con licenza di prova da 15 giorni.
Export table come SQL statement, convertendo i campi date time in formato particolare e ignorando i BLOB altrimenti tutti i campi di tipo timestamp faceva cavolate
Ottenuto file da 1.4GB per una tabella (gli altri circa 1/3)
Compresso RAR, ottenuto file da 35MB circa
Trasferimento file via FTP
UnRar sul mio cliente -> 1.4GB
Esecuzione query di insert da 1.4GB con DBVisualizer Personal (4H siccome mi ero scordato di disabilitare gli indici, ma fa lo stesso)
Ripetuto procedimento per le 3 tabelle
Alcuni proprio non avevano capito che non potevo non comprimere i dati
Come non detto, letto ora la risposta dopo
imho la soluzione piu veolce è (se puoi creare db):
crei un db nuovo
usi la sinstassi a namespace per copiare le tabelle da un db all'altro:
select *
into newdb.dbo.newtablename
from olddb.dbo.oldtablename
unica pecca è che non ti copia PK, FK, IDX e trigger.
in alternativa puoi generare gli script per le 3 tabelle (e le dependency), creare il nuovo DB, generi le tabelle via script, poi usi sempre la sintassi a namespace ma stavolta così:
insert into newtable
select * from oldb.dbo.oldtable
puoi sia forzare l'inserimeto delle primary key oppure puoi fare l'alter table con indici e cazzi vari dopo.
poi fai un backup del db e te lo copi.
per il timestamp non dovrebbero esserci problemi (non sono sicuro al 100%).
crei un db nuovo
usi la sinstassi a namespace per copiare le tabelle da un db all'altro:
select *
into newdb.dbo.newtablename
from olddb.dbo.oldtablename
unica pecca è che non ti copia PK, FK, IDX e trigger.
in alternativa puoi generare gli script per le 3 tabelle (e le dependency), creare il nuovo DB, generi le tabelle via script, poi usi sempre la sintassi a namespace ma stavolta così:
insert into newtable
select * from oldb.dbo.oldtable
puoi sia forzare l'inserimeto delle primary key oppure puoi fare l'alter table con indici e cazzi vari dopo.
poi fai un backup del db e te lo copi.
per il timestamp non dovrebbero esserci problemi (non sono sicuro al 100%).
fare 2 bcp ? una OUT e una IN ?
bcp domedb..nometabella out file.dat -Sdataserver_origine -Uutente -c
e poi
bcp nomedestinazionedb..tabella_destinazione in file.dat -Sdataserver_dest -Uutente -c
edit: ovviamente la tabella di destinazione dee essere vuota o rischi un errore di chiave duplicata nel caso ci fosse....
altrimenti anche con una INSERT LOCATION, se la puoi fare.
aug
bcp domedb..nometabella out file.dat -Sdataserver_origine -Uutente -c
e poi
bcp nomedestinazionedb..tabella_destinazione in file.dat -Sdataserver_dest -Uutente -c
edit: ovviamente la tabella di destinazione dee essere vuota o rischi un errore di chiave duplicata nel caso ci fosse....
altrimenti anche con una INSERT LOCATION, se la puoi fare.
aug
Non l'ho visto tra i tentativi, quindi lo riporto:
Lo script lo puoi eseguire con l'osql (incluso in tutti i SQL Server):
osql -U YourUserName -P YourPassword -S ServerName -d DatabaseName -n-1 -i DriveLetter:SQLFileNameAndPath.sql -o DriveLetter:LogFile.txt
generalmente gli script generati così non hanno grossi problemi, se li esegui con i tools di MS
- Installa il management studio di sql 2008
- Crea una connessione al server 2005
- Tasto dx sul db, tasks, generate scripts
- Selezioni solo le 3 tabelle che ti servono
- Quando ti chiede dove salvare il file clicki su Advanced
- Togli eventuali opzioni che non ti servono (ansi padding, defaults, etc)
- Alla voce 'Types of data to script' imposta 'Schema and data'
- Salva il dump su un unico file, zippalo e trasferiscilo
Lo script lo puoi eseguire con l'osql (incluso in tutti i SQL Server):
osql -U YourUserName -P YourPassword -S ServerName -d DatabaseName -n-1 -i DriveLetter:SQLFileNameAndPath.sql -o DriveLetter:LogFile.txt
generalmente gli script generati così non hanno grossi problemi, se li esegui con i tools di MS