Newsgroup: it.lavoro.informatica
Titolo: SQL Server

Avrei un dilemma
Ho un HD (supponiamo D:\) dove c'è SQL server e nel quale va a scrivere 
i db con relativi dati...
Purtroppo è successo che ora l'HD si è riempito...
Come posso fare a dire che SQL Server deve utilizzare un ulteriore HD 
presente sulla mia macchina (supponiamo E:\) ?
PS: sono disposto anche a migrare tutti DB sull'altro HD (E:\)
Grazie in anticipo a chi mi saprà aiutare,
Giovanni

 Come
Giovanni, sei OT.
BTW, molto probabilmente hai il recovery model impostato su full, e
non hai mai purgato il log file.
Se non e' un db in produzione, ma un ambiente di sviluppo/test,
semplicemente imposta il recovery model su simple, e poi purga il log
file (Task, Shrink, Database, Reorganize .., 5%).
Se sei in produzione, chiama il DBA (diciamo che siamo al'ABC, se non
sai risolvere quel tipo di problema autonomamente, non dovresti
avvicinartici ai DB in produzione ;)).
--
ale
http://ale.riolo.co.uk

Carnefrisca@Work ha scritto:

puoi 'staccare e riattaccare' il database con pathfile diverso.
cerca come si usano
sp_detach_db
sp_attach_db

Carnefrisca@Work ha scritto:

chiedo scusa per l'OT... :-P
comunque il problema è che fatto su ogni singolo db il detach attach non 
è un problema...
quello che vorrei è che sql vada a scrivere tutti i db sull'altro HD

 tutti i db sull'altro HD
Basta che glie lo dici quando crei il DB. Non ti sei accorto che c'è il
path ai dati?
-- 
Ciao!
Luca

 quello che vorrei � che sql vada a scrivere tutti i db sull'altro HD
devi salvare i DB , eliminare l'istanza , ricreare l'istanza nel nuovo path 
, fare l'attach dei database . 

 path ai dati?
Magari deve staccare e riattaccare 42 database, e preferirebbe spostarli 
automaticamente :-)
Putroppo non c'ï¿œ un modo semplice, l'unica possibile soluzione ï¿œ usare una 
query sul db Master per ottenere l'elenco dei database installati, lanciare 
sp_detach_db in loop con un cursore per staccarli tutti, spostare i file a 
mano (xp_cmdshell mi *rifiuto* di usarla) e poi fare qualcosa di simile con 
sp_attach_db.
In genere ï¿œ un tale bagno di sangue che per meno di 30 db si fa prima a 
spostarli a mano che a scrivere script e debuggarli...
Massimo

 a spostarli a mano che a scrivere script e debuggarli...
Su questo sono assolutamente d'accordo.
-- 
Ciao!
Luca

 , fare l'attach dei database .
Si, e poi uscire dalla stanza e rientrare dalla finestra... in realtà
basta staccarli, spostarli e riattaccarli.

 , fare l'attach dei database .
<Si, e poi uscire dalla stanza e rientrare dalla finestra... in realt�
<basta staccarli, spostarli e riattaccarli.
s� ma per spostarli non devi reinstallare l'istanza per aggornare il 
percorso di installazione ? 

 percorso di installazione ?
Ma certo che no. Se hai indici o tabelle particolari fai un backup e
restore, se no basta un copia ed incolla. Il percorso di default per i
dati è una variabile di SQLServer.

> Allora, si potrebbe usare una CLR stored procedure... :D
Oppure un misero batch che fa backup e restore in una diversa location
for each DB..
Ripensandoci, forse è meglio se si mette li e se li sposta tutti e 42
a mano.. ci mette meno e funziona di sicuro.

 a mano.. ci mette meno e funziona di sicuro.
Gi�. In fin dei conti, anche fossero 40, non � questo gran lavoro.
-- 
Ciao!
Luca

 percorso di installazione ?
Quando ti ho dato l'indicazione circa il percorso dei dati per ogni
database, non e che ti abbia detto una cosa a caso!
Non c'e alcuna relazione tra un'istanza di SQL server e dove sono
collocati i dati. In _modo predefinito_ questi vengono collocati alla
creazione in una subdirectory della directory di installazione di SQL
server; il modo predefinito pero puo essere superato attraverso una
impostazione differente della collocazione dei file MDF e LDF che
compongono la base dati. Allo stesso modo, tu puoi disconnettere una o
piu basi dati, spostare i file LDF e MDF che la compongono (sono
riconoscibili, hanno lo stesso nome del database!) e infine
riconnetterli.
Io ho appena fatto una cosa addirittura peggiore: ho disconnesso un
database da un DBMS, l'ho trasportato in un'altra macchina e l'ho
riconnesso al DBMS della nuova macchina. Ho dovuto mettere a posto gli
utenti, ovviamente; ma questa e una cosa che tu non devi fare, perche
il trasferimento e da un disco a un altro della stessa macchina.
-- 
Ciao!
Luca

 riconnetterli.
ho provato ( su SQL server 2005 ) cio� ho scollegato e spostato i file 
MDF\LDF  fuori dalla cartella di default  C\programmi\ms sql 
server\.......\data , li ho messi sempre nello stesso disco dello stesso pc 
, cio� in C\prova .
per� mi da errori sui permessi di accesso usando il gestionale che usa 
appunto quei database  , ho dovuto impostare dal management studio a 
determinate tabelle nuovi permessi agli utenti per eliminare tali errori , 
eppure non dovrebbe dipendere dai permessi NTFS della cartella c\prova
ciao 

 riconnesso al DBMS della nuova macchina.
E dai, "peggiore"... ordinaria amministrazione, se sai cosa stai facendo :-)
E, per inciso, ï¿½ una delle cose che adoro di SQL Server... prova un po' a 
farlo con Oracle! :-/
Massimo

Massimo ha scritto:

Certo perchï¿½ per te 'un database un file fisico' ti pare una bella cosa?
Oracle attraverso tablespace ti fa gestire decentemente i dati 
attraverso una separazione tra file fisici e dati logici.

 attraverso una separazione tra file fisici e dati logici.
Eddai, ma è la fiera del'improvvisazione ? I tablespace esistono da
tempo anche su SqlServer, l'equazione un DB = un File vale solo per i
casi più semplici !

 attraverso una separazione tra file fisici e dati logici.
Sql Server idem.
--
ale
http://ale.riolo.co.uk

 
Si � vero � che non ho mai usato i Filegroup e non sapevo che fossero 
equivalenti ai tablespace di oracle.

 Sql Server idem.
Si � vero, ho gia scritto sopra che non pensavo che i filegroup 
facessero la stessa cosa.

 po' a farlo con Oracle! :-/
Mai provato. D'altra parte, io non faccio il DBA... :D
Per quanto riguarda il 'eggiore', era burlesco.
-- 
Ciao!
Luca


Infatti, qui è peggio. Molto peggio.

 Calmino che non siamo a scuola!
Gi�. Qui siamo in un gruppo di discussione di professionisti che quando
scrivono dovrebbero conoscere ci� di cui discutono, soprattutto prima di
criticare un prodotto un tantinello consolidato e diffuso.
PaF

PaF ha scritto:

Oh, basta!
E' una cosa che in sql server non ho mai usato e in oracle si. Sar� 
perch� la gente preferisce gestire datawarehouse in oracle e non in sql 
server, un motivo ci sar� pure.

 server, un motivo ci sar� pure.
Era meglio se non rispondevi ma ti ringrazio per la risata che mi hai fatto
fare...
PaF

PaF ha scritto:

prego, se la mia risposta non ti � piaciuta pensa quanto tristo � stato 
il tuo intervento

 server, un motivo ci sarà pure.
Non è che mi diverto, però liscia non la posso lasciar passare.
La tua affermazione è falsa, la scelta del DB dipende dall'ambiente
server del cliente, dal budget e dal prodotto che ci si vuol far
appoggiare.
Per il datawarehouse poi la scelta spesso cado proprio su SQLServer
perchè costa meno, non servono competenze particolari e il modulo BI è
incluso nel prezzo.
Oracle al limite lo scelgo per la produzione, per metterlo in cluster
su una batteria di macchine linux et simila, maggiore affidabilità
maggiore costo, maggiori prestazioni.

 
Se un argomento non lo conosci � meglio che non ne parli.

 microsoft e oracle, di che dimensione e mole di dati.
Telecomunicazioni, assicurazioni, enti, i più grandi in Italia.
Conosco personalmente un bravo professionista che non fa altro che DB
multidimensionali su SQLServer dalla mattina alla sera, non costa poco
e  lavora solo per grandi o grandissime aziende.
Per quello che riguarda le dimensioni e moli di dati forse non sai che
attualmente un SqlServer tiene su le chiamate di un operatore
telefonico Italiano, e ti assicuro che sono tante.
Per inciso : personalmente preferisco Oracle.

 basta staccarli, spostarli e riattaccarli.
non � pi� veloce fare il backup, e ripristinare con lo stesso nome del DB ma 
path diverso ?
Andrea

 una separazione tra file fisici e dati logici.
Scusa, ma dove l'hai vista l'equazione "1 db = 1 file" in SQL Server?
Mai sentito parlare di filegroup? :-)
Massimo

maggiore costo, maggiori prestazioni.
Maggiore marketing, pi� che altro... ne ho conosciuti pochi di prodotti 
pesanti come Oracle, a quello un cluster gli server solo per *stare in 
piedi* :-(
Massimo

 eppure non dovrebbe dipendere dai permessi NTFS della cartella c\prova
Non dovrebbe, ma devi assicurarti che l'utenza soto cui gira il servizio di 
SQL Server abbia i pieni diritti sulla cartella in questione, altrimenti non 
puï¿½ accedere ai file fisici di cui ï¿½ composto il database.
Massimo

 piedi* :-(
No dai, Oracle è un mulo incredibile, una volta in piedi ha una
solidità assoluta , a prova di programmatore. E poi gira su più
piattaforme e con tecnologie di high availability che SqlServer si
sogna per il momento. In realtà molto è dovuto a Unix, ma è un sistema
realmente superiore, imho.

Massimo ha scritto:

Si mi hanno giï¿½ linciato sopra, anche se mi pare di capire che il 
filegroup non ï¿½ esattamente come la tablespace di oracle

 filegroup non ï¿½ esattamente come la tablespace di oracle
La gestione ï¿½ ovviamente diversa, ma c'ï¿½ la massima flessibilitï¿½ su dove 
vada fisicamente a finire l'archiviazione di determinate tabelle (o indici).
Massimo

No dai, Oracle � un mulo incredibile
Ottimo paragone: � un lavoratore infaticabile e sopporta grossi carichi, ma 
per farlo muovere ce ne vuole, e se decide di fermarsi non riparte pi� 
nemmeno a calci...
Massimo

 del DB ma path diverso ?
No.
In assoluto, detach e attach e la strategia piu veloce (stacca, sposta
il file, riattacca).
-- 
Ciao!
Luca

 solidità assoluta , a prova di programmatore.
Voglio commentare sulla frase "a prova di programmatore", ma prima
voglio mettere in chiaro che personalmente non ho preferenze per l'uno
o per l'altro, sono entrambi ottimi prodotti, con punti di forza e di
debolezza, con diverse scelte progettuali che ne fanno la migliore
scelta per diversi ambiti applicativi con una certa intersezione.
Questo premesso, conosco un programmatore che ha scritto su Oracle una
query su un certo numero di viste, ognuna contente al massimo 5000
righe, che anche se filtrata per ritornare 1 riga, riempiva la temp
tablespace, qualsiasi fosse la dimensione del tablespace e qualsiasi
fosse lo spazio fisico disponibile, causando il crollo dell'intero
database server.
A prova di programmatore purtroppo c'e' ben poco ;)
--
ale
http://ale.riolo.co.uk

> A prova di programmatore purtroppo c'e' ben poco ;)
Si, forse è vero. Niente resiste a certi sviluppatori.