Avatar billede teepee Nybegynder
02. juni 2008 - 20:06 Der er 7 kommentarer og
1 løsning

Det hele låser og bliver langsomt

Jeg forstår det ikke. Vi har en tabel som bliver opdateret, primært inserts med  nye rækker. Dette sker med jævne mellemrum i løbet af døgnet. Samtidig laves der diverse dataudtræk på denne tabel. Dataudtrækkene tager normalt ca. 2-3 min. og indeholder ca. 100K rækker, men når det rammer ind i opdateringsjobbet tager det 45-60 min. Og her starter misæren, for det kører nemlig hvert kvarter ;-( Vi har prøvet at set'te transaction isolation level til read uncommitted, men det hjalp ikke. Hvordan sikrer jeg at udtrækkene ikke bliver forsinket af nogle simple opdateringer?
Avatar billede teepee Nybegynder
02. juni 2008 - 20:11 #1
Kan lige nævne at det er 2005, men vi havde samme problem på 2000.
Et tilsvarende setup kører problemfrit på Oracle. Hvad sker der med de låse?
Avatar billede HenrikSjang Nybegynder
02. juni 2008 - 20:26 #2
jeg skulle ellers mene at en omgang read uncommitted nok ville have klaret ærterne.
Jeg går ud fra at det er på din select-query at du har prøvet at ændre isolation level? Alternativt kan du kigge nærmere på snapshot isolation level, som er en super feature i sql 2005.
Avatar billede 2c Nybegynder
02. juni 2008 - 20:27 #3
Prøv enventuelt at skrive WITH (NOLOCK) efter  tabel navnene i  FROM clausen
Avatar billede 2c Nybegynder
02. juni 2008 - 20:28 #4
Og så læs hvilke konsekvenser det har på nettet. Eventuelt her: http://www.hotcoding.com/dbs/mysql/26400.html
Avatar billede janus_007 Nybegynder
02. juni 2008 - 22:13 #5
Hvis du bruger ISOLATION LEVEL READ UNCOMMITTED er det det samme som with(nolock)

Er du sikker på der er en lock?

Når begge udtræk kører så forsøg at identificer dem vha. sp_who2 og se om der er nogle blocks?

Hvordan er dine indexes opbygget? Er der indexes? og opdaterer de async?

Når du siger samme setup som Oracle, er det så samme hardware/ maskine?
Avatar billede teepee Nybegynder
02. juni 2008 - 22:49 #6
"Er du sikker på der er en lock?"
Hvad gør ellers at det tager så lang tid. CPU'en på maskinen er ikke særligt belastet.
Der er kun to processer kørende (ud over min administrator) den som kører selecten og den som kører opdateringen. Hvis opdateringen ikke kører, kører selecten fint. Det har intet med hardwaren at gøre. Der er masser af ledige resourcer.
Async indexes? Det må jeg undeersøge.
Avatar billede janus_007 Nybegynder
03. juni 2008 - 09:53 #7
Ja der kan være flere årsager til det tager tid, hvis det ikke er en lock tjaa... så kan det være diskqueue (måske hehe... )
Når begge processer står og kører så åben performance monitor (cmd->perfmon) og se hvor stor diskqueuen er - read/ write.

Bruger dit udtræk et index?

Hvordan ser dit disksetup ud? Altså.. oplys disk/ raids osv. Og ligeledes fortæl hvor datafiler, indexfiles og transactionlogfiles ligger.

/Janus
Avatar billede teepee Nybegynder
02. april 2009 - 14:19 #8
lukker...
Avatar billede Ny bruger Nybegynder

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester