Declassamento DB

giovedì 13 dicembre 2012 - 16.41
Tag Elenco Tags  SQL Server 2000

vittosss Profilo | Junior Member

Ciao a tutti, vi illustro la situazione.
Sql Server 2000 SP4.
2 DB
vorrei dare, per esempio, risorse 80 al primo db e 20 al secondo. o comunque considerare prioritario un db rispetto ad un altro, è possibile?

ciao e grazie
Vittorio

alx_81 Profilo | Guru

>Ciao a tutti, vi illustro la situazione.
>Sql Server 2000 SP4. 2 DB
>vorrei dare, per esempio, risorse 80 al primo db e 20 al secondo.
>o comunque considerare prioritario un db rispetto ad un altro,
>è possibile?
Ahia.... parliamo di una versione un tantino vecchiotta..
Secondo me sei costretto a fare due connection string e decidere tu quali chiamate raggiungono quell'80% per poi smistarle su un db.. (e ovviamente viceversa per il 20%)
Però se l'istanza è la stessa secondo me non ci prendi tanto, se non in fase di lock delle risorse..

>ciao e grazie
di nulla!

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

incalzo.
secondo te le statistiche che sql server mantiene autonomamente può far si che dia + risorse ad un db piuttosto che ad un altro? ovvero, vedo che un db è usato da 100 utenti, l'altro db da 2 di conseguenza do + risorse al primo db

alx_81 Profilo | Guru

>secondo te le statistiche che sql server mantiene autonomamente
>può far si che dia + risorse ad un db piuttosto che ad un altro?
di che statistiche parli?

>ovvero, vedo che un db è usato da 100 utenti, l'altro db da 2 di conseguenza do + risorse al primo db
Chi decide il bilanciamento? Stai parlando in proiezione o ti succede già così?

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

già succede così.

statistiche tipo quelle che aggiorno con "update statistics" o EXEC sp_updatestats

alx_81 Profilo | Guru

>già succede così.
e chi è quello che splitta il carico adesso?

>statistiche tipo quelle che aggiorno con "update statistics" o EXEC sp_updatestats
No quelle sono le statistiche che servono al query engine per decidere che piani applicare per le esecuzioni delle query..

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

ehehehehe e io non ne ho la minima idea di chi splitta il carico!
si dice in giro, tipo leggenda, che qualcuno declasso un db rispetto ad un altro ma non vi è traccia in alcuna sacra scrittura. dunque mi chiedevo se ciò fosse possibile. la medesima applicazione, una punta su db A, la seconda su db B. hanno performance notevolmente differenti dove B è usato molto raramente.

le statistiche gestiscono dunque all'interno del db, non possono essere "sopra" i db?

alx_81 Profilo | Guru

>ehehehehe e io non ne ho la minima idea di chi splitta il carico!
>si dice in giro, tipo leggenda, che qualcuno declasso un db rispetto
>ad un altro ma non vi è traccia in alcuna sacra scrittura. dunque
>mi chiedevo se ciò fosse possibile. la medesima applicazione,
>una punta su db A, la seconda su db B. hanno performance notevolmente
>differenti dove B è usato molto raramente.
>le statistiche gestiscono dunque all'interno del db, non possono
>essere "sopra" i db?
no, le statistiche sono di database.
Per quanto riguarda il carico, se non me lo sai dire tu io posso solo dirti che potrebbe esserci o qualcosa di applicativo (fatto male se ti aspettavi 50 e 50) che dice dove andare..
Il cluster, se c'è sarebbe attivo passivo, sono pochi gli ambienti in cui si è riuscito a spendere soldi per fare un a/a..
dovresti cercare di capire magari profilando le chiamate, la provenienza.. e se puoi cercare di discriminare chi fa cosa..
Qui è dura aiutarti..

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi

vittosss Profilo | Junior Member

no ma credimi, le chiamate sono le medesime e sicuro non c'è alcun intervento in fase chiamante.
mi sembra cmq di capire se su sql server non ci sia possibilità alcuna di stabilire prioritario un db piuttosto che un altro e che non reputi possibile che le statistiche operino un simile comportamento. nemmeno se sul db A fossero sempre aggiornate e sul db B non lo siano da anni?

alx_81 Profilo | Guru

>no ma credimi, le chiamate sono le medesime e sicuro non c'è
>alcun intervento in fase chiamante.
>mi sembra cmq di capire se su sql server non ci sia possibilità
>alcuna di stabilire prioritario un db piuttosto che un altro
dalle applicazioni ci si connette via connectionstring. Se hai una sola connection string vai solo su un db.
Ogni applicazione va su un numero indefinito di sorgenti dati, ma se dici che hai solo una connessione, beh..
l'unico modo di decidere su un db come sql server 2000 è qualcosa di cross database (un linked server, chiamate cross database).
Ma l'entry point è solo uno, ed è il SQL al quale l'applicazione si connette.
Così però, senza avere i dettagli dell'applicazione che chiama, e della tua infrastruttura, ripeto, è veramente difficile..

>e che non reputi possibile che le statistiche operino un simile
>comportamento. nemmeno se sul db A fossero sempre aggiornate
>e sul db B non lo siano da anni?
il fatto che su un db non siano aggiornate è anche perchè quel db è probabilmente usato vicino allo zero (e quind l'aggiornamento non è richiesto)

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.microsoft.com/profiles/Alessandro.Alpi
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5