Jan
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'

Jan
5
2007

Progettare le Group Policy con la testa

Sono due i consigli fondamentali che Microsoft elargisce riguardo la progettazione delle Group Policy: il primo è quello di utilizzarne il minor numero possibile, questo perchè tante GP non solo rallentano enormemente la fase di applicazione delle policies (logon e logoff dell'utente ad esempio), ma rendono particolarmente difficoltosa la gestione e la valutazione del funzionamento complessivo del sistema. Il secondo consiglio è di suddividerle tra quelle che hanno impostazioni che si applicano ai computer e quelle con impostazioni che si applicano agli utenti, avendo cura di disabilitare i computer configuration settings o gli user configuration settings di conseguenza, questo perchè il motore di applicazione delle policy legge TUTTI i file relativi alle configurazioni, anche se una delle due sezioni non è compilata (per impedirne la lettura è necessaria appunto la disabilitazione).
Il risultato è una intoccata flessibilità e una diminuzione dei tempi di applicazione oltre ad una maggiore semplicità di progettazione e gestione.

Jan
5
2007

Azzeramento dei campi identity seed in SQL Server

Questa procedura permette di azzerare i campi identity nelle tabelle sql; è una operazione utile quando ad esempio si fanno delle prove sul database e poi si vuole avere la tabella "pulita", senza cioè avere "buchi" nella numerazione delle colonne che normalmente sono gli ID.
Si utilizza la funzione:
TRUNCATE nome_tabella

Se però esistono vincoli esterni di relazione con altre tabelle non è possibile utilizzare la procedura segnalata; bisogna invece utilizzare la seguente:
DBCC CHECKIDENT ('nome_tabella', RESEED, 1)
Nel caso in cui si voglia riportare l'identity a 1.

DBCC CHECKIDENT ('nome_tabella', RESEED)
In questo caso invece l'identity viene riportata al valore più alto presente nella tabella.

Recent Tweets

Note: For Customization and Configuration, CheckOut Recent Tweets Documentation