I dette særtema om aspekter af AI ser vi på skiftet fra sprogmodeller til AI-agenter, og hvordan virksomheder kan navigere i spændet mellem teknologisk hastighed og behovet for menneskelig kontrol.
Det er næsten for nemt :-) Men Microsoft har et værktøj vedr. best practices du kan downloade fra http://www.microsoft.com/sql/ - jeg har ikke testet det, men det er da et af dem jeg skal have kigget på.
Men et par hurtige tips: Undgå systemdatabaser på samme fysiske disk som pagefile Altid tempdb på separate hurtige diske (gerne stribe uden mirror) Aldrig log og data filer på samme fysiske diske. Aldrig webservices på en SQL Server Aldrig Exchange på en SQL Server Altid kun hw raid, sw raid sløver ned. Altid Raid 10 fremfor Raid 5
Sidst, SQL Server 2000 er mountpoint aware. Dvs du kan med fordel droppe separate drevbogstaver og i stedet mounte datadiskene direkte under SQL Servers data folder.
En anden ting, har du mere end 4 CPU'er og mere end 2GB ram i din server? Hvis ikke, så er der ikke megen fordel ved SQL Server Enterprise Edition fremfor Standard Edition...
Forstod ikke helt... "systemdatabaser på samme fysiske disk som pagefile" - Mener du master, model og msdb? "Altid tempdb på seperat hurtige diske"? "mounte datadiskene direkte under SQL Servers data folder"?
Bemærk at den skal bruges til hosting af websites.
Ok, lidt uddybet: RAID 10 giver større sikkerhed og en smule bedre performance i flerbruger sammenhænge, end RAID 5. Du kan i RAID 10 i bedste fald miste halvdelen af dine diske uden at miste data - minuset er, at du kun får ½ kapacitet af dine diske ud.
RAID 5 giver rimelig performance, men tillader kun at du mister 1 disk - til gengæld kan du udnytte N-1 diske til data. Har du fx 8 * 30 GB datadiske vil du med RAID 10 kunne lagre 120 GB data - med RAID 5 vil du kunne lagre 210 GB.
Drev opsætning (drømmeopsætning :-) C : Operativsystem og swapfil - fysisk disk D : SQL Program filer og systemdatabaser (model, msdb, master) - mirrored disk E (mounted i folder TEMP under D:\SQL Server): TEMPDB - fysisk disk F (mounted i folder DATA under D:\SQL Server): Data og Log - Raid 5 eller 10
Bemærk at jeg har smidt LOG og DATA filer på samme raid. Det er stik mod de normale anbefalinger man ser!
Grunden er, at tilgang til LOG filen er altid sekventiel, mens tilgang til datafilen er random. Derfor vil disk-readahead fungere godt med log, og performance stiger når du har log separat. Men når du har mange databaser - som på et hotel - så vil effekten af mange sekventielle tilgange være random i fht disk - ergo der er ingen fordel.
Det er derfor bedre at blande log og data på samme raid, for at få flere spin (separate fysiske harddiske) i gang per operation.
Hvis database filer er sammen med pagefile (swapfile) så vil du blive straffet dobbelt hvis der swappes - det bør altid undgås.
TEMPDB benyttes kun når der ikke er ram nok til f.eks. store joins og sorteringer - derfor skal det være på separate diske da brugeren venter og du ellers får diskcontention ifht dine data diske.
Mountpoints blev indført med Windows 2000 - det er ligesom unix; Du mounter en disk i en sti fremfor at tildele den et drevbogstav. Faktisk kan du mounte en disk med flere forskellige stier hvis du vil.
Det betyder at når du installerer din SQL Server i folderen D:\SQL Server så vil du kunne mounte et og samme raid som D:\SQL Server\Data og D:\SQL Server\LOG - det er samme raid du har mounted her - så filerne bliver blandet på disken. Hvis du senere får et ekstra raid kan du blot lukke serveren, fjerne D:\SQL Server\LOG, mounte det nye raid der i stedet og flytte logfilerne fra D:\SQL Server\DATA til LOG. Start så SQL Serveren igen - og alt kører. SQL Server "ser" nemlig ikke DATA og LOG som diske, men som foldere.
I øvrigt vedr Database setup: Sørg for at sætte dine databaser til at de ikke har autoshrink og autoclose sat (det koster ad h til i performance). Derudover bør de være sat til ikke at kunne vokse - er det ikke acceptabelt, så sæt dem til at kunne vokse til en max værdi, og sørg for at de vokser med et fast antal MB pr gang fremfor i procent.
Vokser de uhæmmet og/eller i procent vil en database fil på et tidspunkt vokse ud over disk størrelsen. Når det sker, har du et crash. Er det en log fil eller primær database fil, så har du seriøse problemer med at få genskabt den database.
Microsoft har på et tidspunkt fortalt, at ved omkring 500 databaser på en server, så koster den interne administration af databaserne så meget at selve antallet sløver serveren ned. Hvis du når op på omkring 4000 samtidige connections til databaserne, så overvej fiber mode, ellers ikke.
Jeg vil også anbefale at du slår parallel query fra. Parallel query tillader en sql at køre på begge cpu'er - dvs. 1 forespørgsel kan reelt set blokere begge cpu'er - og værre, en gang i mellem løber administrationen af en parallel query løbsk - al cpu tiden går med at synkronisere... Når du slår det fra, så vil en query kun kunne bruge 1 CPU - dvs. kun halvdelen af din processorkapacitet kan optages. Minuset er, at en query kan tage lidt længere tid.
Hmm... ser nu at du skriver 4 diske... Det sætter nogle grænser.
Jeg tror at du kommer bedst om ved at du smækker det hele på et fysisk raid 5 og partitionerer det som C med 5 GB. På C installerer du operativsystem og SQL Server software.
Når SQL Server er installeret, så stopper du MSSQLSERVER servicen, derefter omdøber du folderen C:\Program Files\Microsoft SQL Server\MSSQL\Data til Data_OLD og opretter en ny DATA folder. Nu starter du din Disk Management og mounter den resterende plads under den nye DATA folder. Derefter kopierer du indholdet fra DATA_OLD til DATA og starter MSSQLSERVER servicen.
Overvej lige om du ikke kan få en ekstra disk som hotswap spare - hvis din controller understøtter det? Hotswap gør, at hvis en disk står af, så vil controlleren automatisk sætte reservedisken i drift fremfor den syge. Rigtig smart, og man slipper for at blive hevet ud af sengen klokken 04:48 dagen efter man har været i byen...
Har mulighed for at bytte lidt rundt, og kan sætte 6 x 18 GB 10K diske i steden for.
Min RAID controller er en Adaptec 2100S. Den har kun én kanal. Dermed kun mulighed for ét RAID til alle diskene. Den understøtter følgende RAIDS: 0, 1, 0/1, 5, 0/5
Så det skulle være muligt at opnå den optimale opsætning (drømmeopsætning :)
Du skal have minimum 3 diske til et raid 5 - og så "mister" du en 1/3 af diskkapaciteten (N-1) - jo flere diske du har i et raid 5, jo bedre performer det (simpelthen et spørgsmål om at kunne få flere fysiske spin igang).
Med 6 diske ville jeg holde 1 som hotspare, 1 som fysisk C-DREV (Os+swap) og de resterende 4 som raid 5.
Hmm... jeg gennemlæste lige hvad jeg har skrevet hidtil: Der er single point of failure i mit forslag med disksetup: nemlig på C-drevet. Står det af, så skal du reinstallere (eller restore backup af) OS på en ny disk (har været lidt for træt mens jeg skrev, åbenbart - beklager).
Afhængigt af dit ønske om hvor du vil have bedst sikkerhed kan du vælge at droppe hotsparen og i stedet lave et mirror henover de to diske til C-drevet.
For det første, "Viden" er kun noget værd, når den bliver brugt. Og for det andet - det er faktisk ikke sikkert, at andre mener at det setup jeg har foreslået er det optimale...
Min opsætning bliver som følgende C:\ - RAID1 - OS D:\ - RAID1 - SQL software - System DB's
E:\ - RAID5 - TempDB F:\ - RAID5 - Data & Logs. -------- Under installationen, skal jeg der angive hvor jeg vil installere de forskellige effekter, eller skal jeg blot installere alt på samme drev (d:\) og så efterfølgende flytte de forskellige filer?
Hvordan flytter man TempDB'en til e:\ ?
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.