lug
25
2007

MSDE 2000 non riparte più

Ho appena installato un vecchio MSDE2000 su un server di un cliente; creo una connessione con la management console e vedo il mio bel db; stoppo il db server e... magia delle magie, ora non riesco più a farlo ripartire.

Gli errori che mi vengono dati nell'event viewer sono tre in sequenza:

  • SuperSocket info: ConnectionListen(Shared-Memory (LPC)) : Error 5.
  • Error: 17826, Severity: 18, State: 1
    Could not set up Net-Library 'SSNETLIB'.
  • 17120:
    SQL Server could not spawn FRunCM thread.

Sono riuscito a risolvere il problema andando a verificare la configurazione della client configuration utility (cliconfg dal prompt dei comandi) dove era tutto ok; e la configurazione del server configuration utility (svrnetcn da prompt dei comandi) dove trovo che "stranamente" non ci sono protocolli abilitati per il servizio che sto controllando (ci sono due istanze di MSDE su questa macchina, una è per un sw di backup).
Abilito il protocollo TCP/IP e il NamedPipes e finalmente riesco a far ripartire il servizio.

Son curioso di scoprire cosa abbia scatenato il tutto, da una prima googlata sembrerebbe un baco nell'MSDE2000 dove, se il servizio viene stoppato condelle connessioni aperte (io avevo la management console aperta!) lo stesso va in panne e non riesce più a ripartire.
Buono a sapersi. Verificherò se ci sono degli update che correggono il problema (sicuramente, solo che sono molto pigro io!... )

feb
8
2007

Download backup SQL da remoto via ftp

Mi è capitato in passato di avere dei server di produzione in serverfarm remota, su cui girava sql server con alcuni db. La necessità del cliente era quella di avere in locale i backup aggiornati dei db remoti a prescindere dai backup su nastro effettuati nella serverfarm. Il server era raggiungibile solo tramite protocollo ftp/http.
Dopo aver schedulato un "maintenance plan" di sql che effettuasse il backup, ho preparato uno script che, schedulato adeguatamente, zippasse il backup (per una questione di spazio ovviamente) e lo spostasse in una directory predefinita dell'ftp.
Lato cliente, un altro script schedulato (ad un orario che permettesse al server remoto di fare il backup e zipparlo ovviamente) si occupava di aprire una connessione ftp verso il server remoto e scaricare il backup zippato, avendo cura di cancellare eventuali vecchi backup scaricati prima di n giorni in modo da non riempire il disco nel giro di un mese, e di eliminare lo zip dal server, visto che il download è andato a buon fine.

Lato filesystem normalmente organizzo i db in una cartella DATABASES che contiene al suo interno una directory per ogni db (con molta fantasia nominata proprio con l'identificativo del db). Ogni directory contiene una struttura di questo tipo:
- _maintenance (contiene lo script per zippare il db)
- BACKUP (contiene il backup eseguito da sql server)
- DATA (contiene il file .MDF e .LDF)
- LOG (contiene i file di log del backup di sql)

Lato ftp server invece mantengo una directory per ogni db (può servire anche per server con db di diversi clienti)

Lato client infine, in una directory DATABASES mantengo una struttura a due rami:
- _maintenance (contiene lo script per l'ftp)
- BACKUP (contiene gli zip scaricati)

Come al solito qui (FTP_sqlbackup.zip (2,96 kb)) c'è lo zip, se qualcuno fosse interessato. (Per eseguire lo zip del backup utilizzo pkzipc, ma lo script si può facilmente adattare ad altri prodotti).

Per immagini il processo a grandi linee è il seguente:
LATO REMOTO:
1) Configuro il backup di sql server aprendo la sezione "management" tramite la mmc
 

2) Mi creo un nuovo "maintenance plan" Avendo cura di compilare corretatmente la schedulazione del backup

3) E il posizionamento all'interno del filesystem (.../DATABASES/nomedb/BACKUP se si usa la struttura di cui ho parlato sopra)

4) In pannello di controllo, "scheduled tasks" va aggiunta una operazione pianificata che esegua lo script che zippa il backup (ad un orario che permetta al backup di finire tutte le operazioni)
 


LATO LOCALE:
1) Viene creata la directory per scaricare l'ftp e viene configurato lo script; poi in pannello di controllo, "scheduled tasks" va aggiunta una operazione pianificata che esegua lo script, cancellando lo zip sul server e gli eventuali vecchi backup in locale.
 

gen
10
2007

Copia di un db sql 2000 su un nuovo server

Mi è capitato di dover migrare un db sql 2000 su una macchina diversa a causa di un upgrade generazionale. Riporto la procedura utilizzata:

1. Se possibile mettere il db offline (bisogna assicurarsi che non vi siano connessioni aperte), ovvero eseguire
  USE master EXEC sp_dboption 'dbname', 'offline', 'true' (false lo riporta online)

2. fare la copia dei file MDF dei dati e LDF del log delle transizioni sul server sql dove si vuole migrare la base dati

3. recuperare ID e password crittografata relative agli utenti da migrare ovvero eseguire 
  USE dbname select sid from sysusers where name = 'dbusername'
  USE master select convert( varbinary(32), password ) from syslogins where name = 'dbusername'
si ottengono due valori simili a questi riportati a titolo di esempio:
  0x25C6094E9D2FB44E833414C4EC8997F9
  0x01009466105F269966DDE90E6202EB376778EC61643339B7F2880F8AB2088597


4. creare i nuovi utenti sul nuovo server dati il SID e la PWD crittografa ottenuta al passo precedente ovvero eseguire:
  USE master exec sp_addlogin @loginame = 'userdbname' , @passwd = 0x01009466105F269966DDE90E6202EB376778EC61643339B7F2880F8AB2088597, @sid = 0x25C6094E9D2FB44E833414C4EC8997F9, @encryptopt = 'skip_encryption'

5. eseguire l'attach del db (senza creazione preventiva del db) sul nuovo server ovvero eseguire 
  sp_attach_db @dbname = 'dbname', @filename1 = '<path_su_disco\<nome_file_dati.mdf', @filename2 = '<path_su_disco\<nome_file_log.ldf'

6. se necessario modificare il db di default per gli utenti migrati ovvero eseguire 
  sp_defaultdb @loginame = 'dbusername', @defdb = 'dbname'

Recent Tweets

Note: For Customization and Configuration, CheckOut Recent Tweets Documentation