Newsgroup: it.comp.software.database
Titolo: MS SQL Server...job e utenti

Ciao a tutti.
Sto impazzendo dietro all'agent di SQL Server.
Ho l'esigenza di fare un backup di SQL Server su un NAS. Il nas è
mappato come \\nas\cartella nel percorso dell'unità di backup creata
in SQL Server.
Il registro eventi mi da questo errore:
18024: BackupDiskFile::CreateMedia: BackupDevice
'\\nas\cartella\nas.bak' failed to create. Operating system error =
53(Impossibile trovare il percorso di rete).
Inutile dire che se dallo stesso server faccio \\nas\cartella accedo
immediatamente al percorso.
Ho pensato quindi ad un problema di permessi. Ho provato a:
- far partire il servizio di Agent con un utente Domain Admin (stesso
errore)
- far partire il servizio MS SQL Server con un utente Domain Admin
(stesso errore)
- far partire entrambi i servizi con un utente Domain Admin (stesso
errore)
- a impostare nella cartella Advanced dell' Edit Job Step la voce Run
as User mettendo invece di (self) un utente Domain Admin (stesso
errore)
Mi potete aiutare?
Grazie
giaconet

 immediatamente al percorso.
Hai provato ad eseguire il comando di backup da una sessione di Query
Analyzer, loggato con il tuo utente (che chiaramente deve avere i
permessi di lettura/scrittura sulla condivisione)?
-- 
David Martin


Non avevo ancora provato. Questa la risposta.
Server: Msg 3201, Level 16, State 1, Line 1
Cannot open backup device 'NAS1'. Device error or device off-line. See
the SQL Server error log for more details.
Il device NAS1 è \\nas\cartella\nas1.bak
Se io faccio in esegui \\nas\cartella la cartella si apre senza
problemi e posso copiarci e cancellarci quello che voglio (nel senso
che ho i permessi in scrittura).
Tutto questo è fatto, per adesso, con l'account Domain Admin.
Grazie
giaconet

Ah dimenticavo... il contenuto del SQL Server Logs
BackupDiskFile::OpenMedia: Backup device '\\nas\cartella\nas1.bak'
failed to open. Operating system error = 64(Il nome di rete specificato
non è più disponibile.).
Aiutatemi, vi prego :-(
Bye
giaconet

 non è più disponibile.).
Sinceramente anche io ho avuto problemi a fare il backup in rete.
Comunque, fare il backup su share di rete è una cosa che non consiglio:
in un'operazione legata alla sicurezza (il backup), non va bene
introdurre elementi di incertezza e possibile errore (la rete,
tipicamente elemento non stabile e non affidabile).
Io faccio il backup in locale e poi lo sposto con un dts.
-- 
David Martin

 Io faccio il backup in locale e poi lo sposto con un dts.
E' la prima volta che sento che viene utilizzato il DTS (Data Trasformation 
Service) per fare la copia di un file. Perchè non usi copy/xcopy...? ;-)
Per quanto riguarda l'affidabilità è certamente preferibile eseguire un 
backup su una risorsa di rete che non eseguirlo localmente: hai mai pensato 
all'evenienza che possa succedere qualcosa al disco o alla macchina appena 
termina il backup e prima che si concluda la copia stessa?
Per venire al problema di giaconet, l'unico requisito richiesto per eseguire 
dei backup in rete è che l'account di riferimento abbia permessi di 
scrittura (dati dalla "somma logica" dei permessi share + NTFS) sulla 
risorsa remota.
L'account di riferimento non è l'account connesso interattivamente alla 
macchina (nel caso in cui il backup venga eseguito da Query Analyzer) ma è 
l'account del servizio SQL Server (nel caso di backup interattivo eseguito 
da QA/EM) oppure quello del servizio SQL Agent (nel caso di un job 
schedulato). In entrambi i casi è assolutamente sconsigliabile che gli 
account di servizio dispongano di privilegi elevati (non solo è fuori luogo 
Domain Admins ma lo sono anche un Administrators locale o LocalSystem) è la 
cosa migliore è quella di utilizzare un account di profilo più basso 
possibile (Domain Users only)
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com

 risorsa remota.
E qui, purtroppo, mi sono reso conto che la rete non è così affidabile
(almeno la mia). Nel 80% dei backup eseguiti in rete, i messaggi che
ricevevo erano quelli che ci ha postato giaconet, e sinceramente non c'è
stato verso di capirne i motivi, perché a volte tutto filava liscio...
Continuavo a ricevere la segnalazione di errori del sistema operativo,
per i quali mssql non riusciva a raggiungere la condivisione, ma non per
mancanza di permessi...
Ad un certo punto ho dovuto arrendermi, e ho scelto la meno pericolosa
delle alternative: fare il backup in locale e spostarlo, piuttosto che
farlo in rete con una percentuale di successo del 20%.
Tieni comunque conto che il backup in locale, sta un server con dischi
in raid5, e che dispongo di un'immagine del disco fatta poco prima del
backup... insomma, ci vuole proprio un po' di sf..a :-)
-- 
David Martin

 risorsa remota.
Caro Luca, come dice David, il problema è proprio il fatto che non si
capisce il perché non funzioni. Io sto solo provando con un account
Domain Admin, se mi funzionasse con questo, perfezionerei il tutto con
un account ad hoc. Il problema è che nonstante lo stesso account da
Explorer riesca perfettamente a fare tutto sulla cartella in questione,
come "starter" del servizio SQLSERVERAGENT mi fa fallire puntualmente
il job!!!
Magari è un bug...magari devo installare qualche patch per SQL
SERVER...per la cronaca stiamo parlando di un Windows 2003 server con
SQL SERVER Standard Edition 8.00.760 (SP3)
Quale può essere il problema...ci sto sbattendo la faccia da parecchi
giorni...
grazie cmq
bye
giaconet

 giaconet
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://blogs.aspitalia.com/lucabianchi/
http://mvp.support.microsoft.com

 backup... insomma, ci vuole proprio un po' di sf..a :-)
L'immagine del disco fatta con i file di database in uso serve a ben poco. 
Hai mai provato a riapplicarla...? ;-)
Quanto al RAID5 hai mai pensato al fatto che si possa danneggiare un 
controller, che possano danneggiarsi quasi simultaneamente 2 dischi (che se 
acquistati insieme hanno lo stesso grado di usura, quindi quando arriva 
l'ora del primo tutti gli altri hanno la stessa età), problemi legati ad un 
componente che va in fumo danneggiando non solo la macchina stessa ma 
l'intero rack, allagamenti, furto della macchina ed altri eventi che puoi 
considerare eccezionali quanto vuoi ma pur sempre ragionevoli e tuttaltro 
che improbabili...
Fossi in te cercherei di capire cosa non va nella tua rete e modificherei 
queste consolidate abitudini...
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://blogs.aspitalia.com/lucabianchi/
http://mvp.support.microsoft.com

 queste consolidate abitudini...
Beh, hai messo il dito nella piaga :-)
In effetti devo ricominciare ad indagare sulle possibili cause....
-- 
David Martin

 in SQL Server.
Incredibile, forse per la prima volta riesco a essere utile al news
group... dunque, prova ad andare sull'istanza Sql, tasto dx,
proprietà,startup paramiters. A questo punto aggiungi come parametro:
/T1807. Questo dice a Sql che può vedere periferiche NAS.
 
Fammi sapere se hai risolto così stappo una bottiglia di quello buono :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Ragazzi...io devo essere deficiente...perché non ci riesco proprio.
Allora ho resettato il cervello e sono partito da zero.
Ho preso il servizio SQLSERVERAGENT e l'ho impostato in modo che
partisse come utente_speciale, un utente assolutamente senza nessun
privilegio, una nullità assoluta.
Ho reimpostato l'utente proprio dal pannello apposito di Enterprise
Manager, ma credo sia esattamente la stessa cosa che farlo nel pannello
dei servizi.
Poi sono andato sul NAS e ho impostato i permessi di condivisione con
utente_speciale in lettura scrittura, poi ho controllato anche i
permessi NTFS (il NAS li chiama ACL, ma sono quelli) e utente_speciale
ha permessi di lettura e scrittura.
Bene vado sul job, faccio Start Job e l'errore è sempre lo
stesso!!!!!!!!
Se provo a fare Connetti unità di rete \\nas\cartella, dallo stesso
server, specificando come utente della connessione utente_speciale vedo
tranquillamente la cartella e ci faccio quello che voglio. Ma l'AGENT
di SQL non ne vuole proprio sapere. Mi continua a dare lo stesso
errore!!
Non ho provato con l'opzione suggeritami da benjo (di impostare /T1807
nei parametri di startup) perché dovrei riavviare il servizio di
MSSQLSERVER e non posso se non la notte :-(
Ma come devo fare??? Mi devo rassegnare??? :-(((
Bye
giaconet

 Ok, ma allora cosa mi consigli per eventi più catastrofici?
Clustering, Log Shipping, Database Mirroring, Replica, altro...
Attenzione che ciò non significa poter prescindere dall'implementazione di 
una efficiente politica di backup (fondamentale eseguire anche delle prove 
di ripristino che pochi fanno) e l'adozione di soluzioni RAID (subordinato 
al budget e alle specifiche necessità).
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com

 giaconet
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com

 Fammi sapere se hai risolto così stappo una bottiglia di quello buono
Stappala lo stesso... ;-)


 Stappala lo stesso... ;-)
 


 Almeno tentar non nuoce a questo punto.
Per risolvere un problema ci sono 2 strade. Una passa per analizzare il 
problema č trovare una soluzione mirata sulla base di dati oggettivi (event 
log, monitoraggi, misurazioni, ecc) e l'altra andare per prove ed errori in 
maniera casuale o quasi
Entrambe possono portare alla soluzione ma con la prima strada sei 
ragionevolmente sicuro di non avere degli effetti collaterali (o perlomeno 
li hai studiati in fase di risoluzione del problema); la seconda ti espone a 
vulnerabilitŕ dove la "non conoscenza" di ciň che hai fatto ti mette nelle 
condizioni di non poter trarne giovamento per analoghe attivitŕ in futuro. 
Inoltre il dubbio di aver aperto qualche falla nel tuo sistema dovrebbe 
perlomeno balenarti in mente ed il rischio č proporzionale alla quantitŕ di 
attivitŕ "inconscie" che hai eseguito.
Delle 2 strade indicate, la seconda non la prenderei proprio in 
considerazione...


 considerazione...
Concordo cone te, ci mancherebbe. Infatti figuriamoci se con la mia
limitata conoscenza di Sql mi inventavo di mettere il trace flag, in
produzione per giunta. Se l'ho fatto è perchè mi è stato detto da
consuletni microsoft ai quali si appoggia la mia azienda. Fatto quello il
problema è stato risolto. Poi se una paga per un servizio di consulenza
per avere soluzioni errate questo è un altro discorso. 
Come hai detto però tu hai giornalmente a che fare con backup effettuati
su risorse condivise e non ha mai implementato il trace flag /T1807.
Sicuramente sono in errore io, lungi da me il voler essere responsabile di
problemi per consigli sbagliati :-(
