---

Jeg har en rapport i MS-Access som har kørt fint (ca. 5 sekunder),
indtil den pludselig overnight tog 20 minutter. Jeg kører den hver
morgen, og det er efterhånden blevet lidt træls :(

MySQL er linket til en MS-Access database via odbc-connector 3.51.19.
For at løse problemet har jeg forsøgt følgende:
1) Repareret og optimeret MySQL databasen v.hj.a. PHPMyAdmin
2) Prøvet at oprette en helt ny database, lavet nye links, og kopieret
forespørgsler og rapporter over fra den gamle database
3) Kopieret hele databasen over på en anden klient med MS-Access og
herfra prøvet at køre rapporten.

Intet har hjulpet en tøddel. Der er andre rapporter i databasen som
kører hurtigt som de altid har gjort - kun denne ene rapport er dræbende
langsom.

Nogen idéer til hvordan jeg kan fejlsøge? Er der nogle værktøjer således
at jeg kan få et hurtigt overblik over evt. forskelle mellem den MySQL
database der giver problemer og en anden MySQL database med lignende
struktur som kører fint? Umiddelbart virker det som et indeks der er
blevet smidt, men jeg kan ikke se hvor.

Mogens

---

Rainman wrote:
> Jeg har en rapport i MS-Access som har kørt fint (ca. 5 sekunder),
> indtil den pludselig overnight tog 20 minutter. Jeg kører den hver
> morgen, og det er efterhånden blevet lidt træls :(
>
> MySQL er linket til en MS-Access database via odbc-connector 3.51.19.
> For at løse problemet har jeg forsøgt følgende:
> 1) Repareret og optimeret MySQL databasen v.hj.a. PHPMyAdmin
> 2) Prøvet at oprette en helt ny database, lavet nye links, og kopieret
> forespørgsler og rapporter over fra den gamle database
> 3) Kopieret hele databasen over på en anden klient med MS-Access og
> herfra prøvet at køre rapporten.
>
> Intet har hjulpet en tøddel. Der er andre rapporter i databasen som
> kører hurtigt som de altid har gjort - kun denne ene rapport er dræbende
> langsom.
>
> Nogen idéer til hvordan jeg kan fejlsøge? Er der nogle værktøjer således
> at jeg kan få et hurtigt overblik over evt. forskelle mellem den MySQL
> database der giver problemer og en anden MySQL database med lignende
> struktur som kører fint? Umiddelbart virker det som et indeks der er
> blevet smidt, men jeg kan ikke se hvor.


Det ville også være mit første gæt. Har du kontrolleret, at der er alle
de tænkelige indekser på alle de tabeller/felter, den langsomme rapport
bruger.

En anden sag er jo, at hvis databasen vokser, så vokser CPU-tiden osse.
Access er ikke just client-server, så ved en kompliseret forspørgsel
skal den hente samtlige recordkombinationer ind i processoren. Og det
kan godt løbe op..

Kan der være opstået fejl i data, så dine joins resultere i et stort
antal records? Hvis der pludselig optræder to ens værdier i et felt,
hvor din join forventer en een-til-mange, men nu skal slås med
mange-til-mange.
Det ses jo ikke af indekseringen..

---

Gert Krabsen wrote:
> Rainman wrote:
>> Jeg har en rapport i MS-Access som har kørt fint (ca. 5 sekunder),
>> indtil den pludselig overnight tog 20 minutter. Jeg kører den hver
>> morgen, og det er efterhånden blevet lidt træls :(
>>
>> MySQL er linket til en MS-Access database via odbc-connector 3.51.19.
>> For at løse problemet har jeg forsøgt følgende:
>> 1) Repareret og optimeret MySQL databasen v.hj.a. PHPMyAdmin
>> 2) Prøvet at oprette en helt ny database, lavet nye links, og kopieret
>> forespørgsler og rapporter over fra den gamle database
>> 3) Kopieret hele databasen over på en anden klient med MS-Access og
>> herfra prøvet at køre rapporten.
>>
>> Intet har hjulpet en tøddel. Der er andre rapporter i databasen som
>> kører hurtigt som de altid har gjort - kun denne ene rapport er
>> dræbende langsom.
>>
>> Nogen idéer til hvordan jeg kan fejlsøge? Er der nogle værktøjer
>> således at jeg kan få et hurtigt overblik over evt. forskelle mellem
>> den MySQL database der giver problemer og en anden MySQL database med
>> lignende struktur som kører fint? Umiddelbart virker det som et indeks
>> der er blevet smidt, men jeg kan ikke se hvor.
>
>
> Det ville også være mit første gæt. Har du kontrolleret, at der er alle
> de tænkelige indekser på alle de tabeller/felter, den langsomme rapport
> bruger.
>
> En anden sag er jo, at hvis databasen vokser, så vokser CPU-tiden osse.
> Access er ikke just client-server, så ved en kompliseret forspørgsel
> skal den hente samtlige recordkombinationer ind i processoren. Og det
> kan godt løbe op..
>
> Kan der være opstået fejl i data, så dine joins resultere i et stort
> antal records? Hvis der pludselig optræder to ens værdier i et felt,
> hvor din join forventer en een-til-mange, men nu skal slås med
> mange-til-mange.
> Det ses jo ikke af indekseringen..

Det mystiske er at jeg faktisk har 4 ens databaser (4 forskellige
oscommerce sites). For hver database kører jeg hver morgen en rapport
der laver pakkesedler og en der laver fakturaer. Så to identiske
rapporter på 4 identiske databaser, hvor rapport 2 så bare lige
pludselig fra een kørsel til næste øgede eksekveringstiden 2-300 gange!

Den eneste "mærkværdighed" ved den database hvor problemet opstod er at
det er den største af de 4 databaser. Men med en samlet MySQL database
størrelse på 60 MB er det efter min mening stadig en lilleput, og det er
langt fra alle tabeller i databasen som bruges af rapporten.

Det virker lidt som om at rapporten har en delay faktor på 20 minutter
hvor der intet laves, og efter denne lange pause, så afvikles den bare
helt normalt på nogle få sekunder.

---

Rainman <rainman@rainman.com> writes:

> Det virker lidt som om at rapporten har en delay faktor på 20 minutter
> hvor der intet laves, og efter denne lange pause, så afvikles den bare
> helt normalt på nogle få sekunder.

Det er ikke en antivirus der har set sig gal på den, vel?

Har MySQL mulighed for at lave en "EXPLAIN PLAN" så den fortæller hvad
den har tænkt sig at lave? Jeg har set med en gammel Oracle at den
altså mente at det var en god ide at lave fuldt tablescan på den store
tabel i joinet for hver række i den lille tabel, og det var altså
hurtigere den anden vej rundt.

Det kunne fint passe med at den bare står og gumler i 20 minutter for
at lave et resultat den skal bruge, og så vips er den færdgi.
--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen wrote:
> Rainman <rainman@rainman.com> writes:
>
>> Det virker lidt som om at rapporten har en delay faktor på 20 minutter
>> hvor der intet laves, og efter denne lange pause, så afvikles den bare
>> helt normalt på nogle få sekunder.
>
> Det er ikke en antivirus der har set sig gal på den, vel?
>
> Har MySQL mulighed for at lave en "EXPLAIN PLAN" så den fortæller hvad
> den har tænkt sig at lave? Jeg har set med en gammel Oracle at den
> altså mente at det var en god ide at lave fuldt tablescan på den store
> tabel i joinet for hver række i den lille tabel, og det var altså
> hurtigere den anden vej rundt.
>
> Det kunne fint passe med at den bare står og gumler i 20 minutter for
> at lave et resultat den skal bruge, og så vips er den færdgi.

Jeg er lidt i tvivl om hvad jeg har af muligheder for at få log-data ud
af MySQL, og om jeg skal finde data på serveren eller på klienten? Men
vedr. anti-virus kan jeg da lige sige at jeg netop har sparket Norton
Internet Security på porten og installeret AVG's ditto. Det har ikke
gjort en forskel, andet end at jeg fandt ud af at Norton skal man ikke
installere på sin PC :)

Og jeg har netop prøvet at sætte index på alle tænkelige felter som
bruges til opslag, og det medførte absolut ingen ændring.

Mit skrækscenarie er om den en dag finder på at multiplicere tiden med
en faktor godt 100 igen. Så er jeg rent ud sagt på røven :(

---

Rainman <rainman@rainman.com> writes:

> Jeg er lidt i tvivl om hvad jeg har af muligheder for at få log-data
> ud af MySQL, og om jeg skal finde data på serveren eller på klienten?

Det lyder som et godt tidspunkt at begynde at læse manualen til
databasen mht faciliteter, og se om MySQL har nogen supportfora - kan
jo være noget andre har set. Kan være du skal til lommen og spørge
MySQL firmaet direkte.


--
Thorbjørn Ravn Andersen

---

Rainman wrote:
> Gert Krabsen wrote:
>
>> Rainman wrote:
>>
>>> Jeg har en rapport i MS-Access som har kørt fint (ca. 5 sekunder),
>>> indtil den pludselig overnight tog 20 minutter. Jeg kører den hver
>>> morgen, og det er efterhånden blevet lidt træls :(
>>>
>>> MySQL er linket til en MS-Access database via odbc-connector 3.51.19.
>>> For at løse problemet har jeg forsøgt følgende:
>>> 1) Repareret og optimeret MySQL databasen v.hj.a. PHPMyAdmin
>>> 2) Prøvet at oprette en helt ny database, lavet nye links, og
>>> kopieret forespørgsler og rapporter over fra den gamle database
>>> 3) Kopieret hele databasen over på en anden klient med MS-Access og
>>> herfra prøvet at køre rapporten.
>>>
>>> Intet har hjulpet en tøddel. Der er andre rapporter i databasen som
>>> kører hurtigt som de altid har gjort - kun denne ene rapport er
>>> dræbende langsom.
>>>
>>> Nogen idéer til hvordan jeg kan fejlsøge? Er der nogle værktøjer
>>> således at jeg kan få et hurtigt overblik over evt. forskelle mellem
>>> den MySQL database der giver problemer og en anden MySQL database med
>>> lignende struktur som kører fint? Umiddelbart virker det som et
>>> indeks der er blevet smidt, men jeg kan ikke se hvor.
>>
>>
>>
>> Det ville også være mit første gæt. Har du kontrolleret, at der er
>> alle de tænkelige indekser på alle de tabeller/felter, den langsomme
>> rapport bruger.
>>
>> En anden sag er jo, at hvis databasen vokser, så vokser CPU-tiden
>> osse. Access er ikke just client-server, så ved en kompliseret
>> forspørgsel skal den hente samtlige recordkombinationer ind i
>> processoren. Og det kan godt løbe op..
>>
>> Kan der være opstået fejl i data, så dine joins resultere i et stort
>> antal records? Hvis der pludselig optræder to ens værdier i et felt,
>> hvor din join forventer en een-til-mange, men nu skal slås med
>> mange-til-mange.
>> Det ses jo ikke af indekseringen..
>
>
> Det mystiske er at jeg faktisk har 4 ens databaser (4 forskellige
> oscommerce sites). For hver database kører jeg hver morgen en rapport
> der laver pakkesedler og en der laver fakturaer. Så to identiske
> rapporter på 4 identiske databaser, hvor rapport 2 så bare lige
> pludselig fra een kørsel til næste øgede eksekveringstiden 2-300 gange!
>
> Den eneste "mærkværdighed" ved den database hvor problemet opstod er at
> det er den største af de 4 databaser. Men med en samlet MySQL database
> størrelse på 60 MB er det efter min mening stadig en lilleput, og det er
> langt fra alle tabeller i databasen som bruges af rapporten.
>
> Det virker lidt som om at rapporten har en delay faktor på 20 minutter
> hvor der intet laves, og efter denne lange pause, så afvikles den bare
> helt normalt på nogle få sekunder.

Jeg har ikke oplevet det i mySql, men ofte i Access. Og der har det
altid skyldtes et klokket join - formentlig fordi den som Thorbjørn
skriver laver det fulde tablescan på den forkerte tabel.

Igen: Databaserne er ens, men data vel ikke? Har du checket, at der ikke
er opstået en dublet-værdi i et felt, hvor det ikke burde.

I Access defineres to typer index på et felt:

1. indexeret - dubletter tilladt
2. indexeret - dubletter ikke tilladt

Jeg ved ikke om den samme skelnen findes i mySql

---

> I Access defineres to typer index på et felt:
>
> 1. indexeret - dubletter tilladt
> 2. indexeret - dubletter ikke tilladt
>
> Jeg ved ikke om den samme skelnen findes i mySql

Det vil jeg tro.
Når man opretter en tabel, vælger man dels om det skal være auto_increment,
og dels om det skal være primærnøgle.

Har aldrig prøvet det, da jeg altid har valgt auto_increment og Primary på
første kolonne. Hvis dubletter skulle tillades, røg hele fidusen jo ved at
have et id-felt - set med mine øjne.

Havde i øvrigt gennem hele tråden svært ved at forstå, om det var Access
eller MySQL, der lavede narrestreger.

---

Philip Nunnegaard wrote:
>> I Access defineres to typer index på et felt:
>>
>> 1. indexeret - dubletter tilladt
>> 2. indexeret - dubletter ikke tilladt
>>
>> Jeg ved ikke om den samme skelnen findes i mySql
>
>
> Det vil jeg tro.
> Når man opretter en tabel, vælger man dels om det skal være
> auto_increment, og dels om det skal være primærnøgle.
>
> Har aldrig prøvet det, da jeg altid har valgt auto_increment og Primary
> på første kolonne. Hvis dubletter skulle tillades, røg hele fidusen jo
> ved at have et id-felt - set med mine øjne.

Det er skam ikke id-feltet jeg tænker på, men de andre felter i
tabellen. Det være sig ordrenr, varenr. etc - eller såmænd navn.

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse
news:46d61613$0$69268$edfadb0f@dread12.news.tele.dk...
>> I Access defineres to typer index på et felt:
>>
>> 1. indexeret - dubletter tilladt
>> 2. indexeret - dubletter ikke tilladt
>>
>> Jeg ved ikke om den samme skelnen findes i mySql
>
> Det vil jeg tro.
> Når man opretter en tabel, vælger man dels om det skal være
> auto_increment, og dels om det skal være primærnøgle.
>
> Har aldrig prøvet det, da jeg altid har valgt auto_increment og Primary på
> første kolonne. Hvis dubletter skulle tillades, røg hele fidusen jo ved at
> have et id-felt - set med mine øjne.
>
> Havde i øvrigt gennem hele tråden svært ved at forstå, om det var Access
> eller MySQL, der lavede narrestreger.

Har du prøvet at genopfriske linkene til tabellerne?

En anden mulighed for at se, om det er i Access eller i MySQL forsinkelsen
ligger var jo at udføre forespørgslen direkte i MyAdmin (forudsat, at den
ikke behandler lokale Access tabeller).

Hvis den udføres hurtigt i MyAdmin, kunne du jo overveje at ændre
forespørgslen i Access til en fremsendelsesforespørgsel, hvor hele arbejdet
laves af MySQL og Access kun skal tage sig af resultatsættet.
Der kan faktisk være meget tid at spare, somme tider.

---

Kaj Julius wrote:
>
> Har du prøvet at genopfriske linkene til tabellerne?
Det havde jeg ikke - for nylig i hver fald - men prøvede og det gjorde
ingen forskel :(
>
> En anden mulighed for at se, om det er i Access eller i MySQL forsinkelsen
> ligger var jo at udføre forespørgslen direkte i MyAdmin (forudsat, at den
> ikke behandler lokale Access tabeller).
Der er ingen lokale databaser, men jeg bruger nogle access funktioner
såsom Iif, så når jeg prøver at køre rapporterne i MyAdmin så fejler de.

Det tyder lidt på - som også foreslået tidligere i tråden, at det er et
index der er gået i smadder. Har undersøgt at jeg ikke har dubletter i
et unikt indeks, så det kan udelukkes. Som nævnt hjælper det heller ikke
at lave en repair/optimize.

Ville det være en idé at prøve at dumpe hele databasen og læse en frisk
back-up ind? Så vil index vel blive gendannet. Der er dog det problem
med at MySQL aborter efter en vis tid, så min database er nok for stor
til at blive opdeteret i et hug medmindre man kan overstyre denne
tidsparameter (jeg har root access til serveren).

Det ville dog være rart om man på sql-serveren kunne se i en log hvor
det er tidsforbruget er. Så burde det vel være muligt at indkredse synderen?
>
> Hvis den udføres hurtigt i MyAdmin, kunne du jo overveje at ændre
> forespørgslen i Access til en fremsendelsesforespørgsel, hvor hele arbejdet
> laves af MySQL og Access kun skal tage sig af resultatsættet.
> Der kan faktisk være meget tid at spare, somme tider.
>
>

---

Rainman wrote:
> Det ville dog være rart om man på sql-serveren kunne se i en log hvor
> det er tidsforbruget er. Så burde det vel være muligt at indkredse
> synderen?

http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

/ Carsten

---

Carsten Pedersen wrote:
> Rainman wrote:
>> Det ville dog være rart om man på sql-serveren kunne se i en log hvor
>> det er tidsforbruget er. Så burde det vel være muligt at indkredse
>> synderen?
>
> http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html
>
> / Carsten
>
Blot som afslutning på tråden så lykkedes det at få problemet løst :)
Det var ikke en slow query på MySQL serveren, men en tabel linket til en
anden database. Jeg kører 4 identiske databaser som jeg i deres helhed
har linket til MS-Access (i hver deres MS-Access database). Dog med den
ene undtagelse af tabel X i database 1 også bruges i de tre andre
databaser.

Det giver ingen problemer med at afvikle rapporter i database 2 og 3,
men for database 4 gav det den nævnte lange afvikling. Trods at alle
links var genopfrisket, så blev problemet først løst ved at lave en kopi
af tabel X og placere den inde i database 4. Vupti, og rapporten kører
som en mis.

Det forstår jeg ikke en brik af, men sådan er der jo så meget. Men
glæden er stor over at have løst denne "driller" o)

---

On Wed, 29 Aug 2007 23:10:10 +0200, Gert Krabsen
<fjernkrabsen@fjernkrabsenfjern.dk> wrote:

>I Access defineres to typer index på et felt:
>
>1. indexeret - dubletter tilladt
>2. indexeret - dubletter ikke tilladt
>
>Jeg ved ikke om den samme skelnen findes i mySql

Det gør den. index og unique index.

I og med at to NULL-felter ikke er lig hinanden, så kan man, hvis NULL
er tilladt, godt have flere NULL-værdier i en kolonne, som i øvrigt er
unique.

--
- Peter Brodersen
Kendt fra Internet