Publicat per Sergi Sinyol a 11 Abril 2009
Si volem migrar un servidor SQL a un altre servidor més nou, o bé a una nova versió de sistema operatiu o fins i tot passar a 64 bits, podem utilitzar el mètode de attach/deattach.
Aquest mètode consisteix en fer un deattach de les bases de dades, moure-les i tornar a fer un attach.
Però si fem això, es possible que algunes aplicacions no funcionin. Això és així, perquè cal tornar a crear els logins del SQL en el nou entorn.
Si resumim, els passos serien els següents:
- Fer un inventari de totes les bases de dades, registrant quin usuari és el seu owner, quin collation tenen i on estan ubicats els arxius
- Executem el script que hi ha a l’article How to transfer the logins and the passwords between instances of SQL Server 2005
- Un cop executat, posem EXEC sp_help_revlogin
- Això ens genera un script. El copiem en un arxiu
- Fem una còpia de les bases de dades que hem apuntat en el primer punt.
- Aleshores ja podem instal·lar el nou servidor SQL 2005, preferiblement amb el mateix nom si no volem tocar la configuració de les aplicacions.
- El posem al domini, li instal·lem els binaris, i li posem el SP3 (o el que toqui).
- Amb el configurador de Surface, fem que els protocols remots siguin TCP/IP i Named Pipes.
- També hem de configurar els antics administrador que hi havia en l’altra instància de SQL.
- Aleshores ja podem fer un attach de les bases de dades, una per una, vigilant que el Propietari sigui el mateix que hi havia.
- Un cop afegides les bases de dades, executem l’script que ens ha generat el sp_help_revlogin.
- I ara ja podem provar de connectar l’aplicació.
Publicat en Català, sql | Etiquetat: sql, sql 2005 | Deixa un Comentari »
Publicat per Sergi Sinyol a 14 Març 2007
Les meves recomanacions a l’hora de crear un RAID són:
- No posar MAI un RAID 5. La tecnologia de RAID 5 es molt lenta en escriptura, penalitzant qualsevol tipus de BBDD. S’ha d’utilitzar en l’últim cas, mai en una configuració inicial.
- Revisar que la controladora RAID tingui bateria per poder activar la caché d’escriptura. En el servidors HP Proliant, la bateria BBWC (Battery Backed Write Cache) no ve per defecte i si no està disponible no pots activar la caché d’escriptura per Hardware. Tot i que només val uns 100€, la perdúa de rendiment es molt gran. Es probable que un PC normalet amb un disc IDE/ATA (que porten inclosa una cache de 8Mb) sigui més ràpid que un servidor sense cache d’escriptura.
- Posar sempre el màxim de discs petits, millor que pocs discs més grans
- Especificar sempre RAID 0+1, o 1+0, o 10 (segons el fabricant, ja que no hi ha un estandard), millor que RAID 1 a seques. Un RAID 1 de dos discs generalment és un simple mirror, i el rendiment no millora, ja que es treballa amb un disc i la controladora actualitza l’altre. En canvi RAID 0+1 parteix els dos discs, i quan ha de gravar dades, grava la meitat a cada disc, per tant, triga justament la meitat.
- Separar els tipus d’accés diferents en discs físics (o volums) diferents. En les BBDD transaccionals (Exchange, SQL server, Oracle, etc) veiem que els arxius de dades es divideixen en dues parts. El arxiu on estan les dades propiament i l’arxiu o arxius on estan els logs (o redo logs). Mentre l’arxiu de les dades té un accés aleatori (es pot anar a llegir o escriure a qualsevol part de l’arxiu), els logs sempre són seqüencials. Per tant, si tenim un volum només amb les dades seqüencials, la lectura avançada de la caché será més útil, i el rendiment millorará.
- Separar SEMPRE les unitats de disc de les unitats de Cinta. Mai s’han de barrejar en un mateix bus SCSI una unitat de Cinta i un array de discs. Això provocará que els discs vagin a la velocitat de les cintes.
- Mai punxar discs de diferent versió de SCSI al mateix bus. Si tenim discs Ultra2, Ultra160 o Ultra320 i els posem junts, tots aniran a Ultra2.
- El mateix passa amb les revolucions. Juntar discs de 10K amb discs de 15K fa que tots vagin al rendiment del més lent.
- Cal anar en compte amb les cabines de disc. Algunes cabines de disc han quedat obsoletes, i tot i que externament es connecten a 2 Gbps (o a 4 Gbps), i fins i tot acceptin discs Ultra320, pot ser perfectament que el bus intern només funcioni amb tecnologia Ultra2, baixant tot el rendiment del sistema a Ultra2.
- Afegir discs SATA per realitzar el backup. Els discs SATA de 500 Gb tenen un cost molt més baix que els discs SCSI, i permeten realitzar un primer backup a disc que es fará en minuts. Després aquest backup es pot passar a Cinta, per poder endur-nos les dades fora del CPD Principal.
Two core RAID levels are of value for a database server: striping with parity (RAID 5) and striped mirror (RAID 0+1). The best overall option is to choose RAID 0+1 (also called RAID 01 or “striped mirror”). RAID 5 can be used in certain circumstances, but is generally more expensive in the long run, and less reliable.
Totes aquestes recomanacions es poden trobar en aquests links:
Best Practices Common to Multiple Architectures
SQL Server 2000 Operations Guide: Capacity and Storage Management
Publicat en Català, Exchange, HP, Microsoft, Storage, sql | Deixa un Comentari »
Publicat per Sergi Sinyol a 5 Febrer 2007
En algunes configuracions el arxiu de log del Sharepoint pot creixer fins ocupar la totalitat del disc físic.
He vist casos d’arxius de log de 90Gb mentre el tamany de la BBDD es de 1 Gb.
Per tal d’evitar això, cal fer un pla de manteniment periòdic que faci un SHRINK de la BBDD.
En cas que no haguem fet el manteniment periòdic i ens trobem amb el problema, podem fer el següent:
(millor fer backup sempre abans)
USE STS_INFODECDC_1;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE STS_INFODECDC_1
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (STS_INFODECDC_1_log, 100);
GO
-- Reset the database recovery model.
ALTER DATABASE STS_INFODECDC_1
SET RECOVERY FULL;
GO
No cal provar amb DBCC SHRINKDATABASE ni amb DBCCSHRINKFILE, ja que aquestes opcions gairebé no reduiran l’arxiu de log, ja que està realment en ús.
Per veure l’us de l’arxiu de log:
DBCC SQLPERF (LOGSPACE);
i ens mostrarà l’us del mateix. En aquest cas posava 93% used.
També es recomana posar un límit al creixement de l’arxiu de log, ja que és preferible que s’aturi el sharepoint per falta d’espai assignat de log, que no pas trobar-se el disc físic ple.
En cas d’arribar al límit de l’arxiu de log es veurà perquè el sharepoint no pot escriure arxius nous.
Podem veure el que recomana Microsoft aquí
Publicat en Català, Microsoft, Procediment, Sharepoint, sql | Deixa un Comentari »
