/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Hvad ville du gøre?
Fra : Lars Aagaard


Dato : 30-03-03 15:59

Jeg har netop konverteret min side fra Access til MS-SQL.
Det forløb rimelig smertefrit, desværre er loadtiden for mine sider,
efter dette skifte, blevet væsentligt længere...

Jeg har nu undersøgt frem og tilbage - min udbyder siger at jeg skal
flytte alle min sql'er til Stored Procedures på serveren. (Stort arb....)

Jeg har overvejet at forsøge mig med mySQL i stedet, selvom en omlægning
af ALLE mine ASP-sider til denne database virker lidt uoverskueligt...

Har du erfaringer med hastigheden de to databaser imellem?
- og hvad ville du anbefale?

--
Med venlig hilsen
Lars Aagaard

Lystfisker Forum - Danmarks mest aktive forum for lystfiskere
http://www.123nu.dk/
Fangster.dk - Din personlige fangstjournal på nettet.
http://www.fangster.dk/



 
 
Troels Arvin (30-03-2003)
Kommentar
Fra : Troels Arvin


Dato : 30-03-03 16:13

On Sun, 30 Mar 2003 16:59:15 +0200, Lars Aagaard wrote:
> Jeg har netop konverteret min side fra Access til MS-SQL. Det forløb
> rimelig smertefrit, desværre er loadtiden for mine sider, efter dette
> skifte, blevet væsentligt længere...

Er det store datamængder (== store tabeller)? - I så fald: Har du kigget
på, om dine tabeller er indekseret korrekt?

Kan det evt. skyldes, at der er dårligere forbindelse fra din ASP til
MSSQL-databasen end der var til Access-databasen? (Måske MSSQL afvikles
fra en anden server, som der er langsommere forbindelse til?) Ved du, om
det er connect-tiden, der er langsommere nu, eller går det bare generelt
langsommere?

Opererer man i ASP-verdenen med persistente databaseforbindelser? - I så
fald: Udnytter du persistente forbindelser?

Kender du andre, der benytter MSSQL på webhotellet? - Hvad siger de: Er
det mon simpelthen en langsom MSSQL-installation, de har?

> Min udbyder siger at jeg skal
> flytte alle min sql'er til Stored Procedures på serveren. (Stort
> arb....)

- Og dermed binde dig yderligere til deres service? Smart

At afvikle queries som stored procedures betyder ikke nødvendigvis
højere hastighed.

> Jeg har overvejet at forsøge mig med mySQL i stedet
Der er mange standard SQL features, som MySQL ikke understøtter, så ja,
nogle gange er konverteringen besværlig. Er PostgreSQL en option på dit
webhotel?

/Troels

Lars Aagaard (30-03-2003)
Kommentar
Fra : Lars Aagaard


Dato : 30-03-03 16:44

Hej Troels,

Tak for svaret.

> Er det store datamængder (== store tabeller)? - I så fald: Har du kigget
> på, om dine tabeller er indekseret korrekt?

Jeg det er store datamængder, og mit kendskab til indeksering er begrænset,
så det muligt at problemet ligger her....

> Kan det evt. skyldes, at der er dårligere forbindelse fra din ASP til
> MSSQL-databasen end der var til Access-databasen? (Måske MSSQL afvikles
> fra en anden server, som der er langsommere forbindelse til?) Ved du, om
> det er connect-tiden, der er langsommere nu, eller går det bare generelt
> langsommere?

Det er min fornemmelse at det er connect-tiden, som er blevet meget langsommere
Access databasen var ustabil, men kørte MEGET hurtigere. MSSQL afvikles på
en anden server.

> Opererer man i ASP-verdenen med persistente databaseforbindelser? - I så
> fald: Udnytter du persistente forbindelser?

Persistente databaseforbindelser? - det siger mig ikke så meget, så hvis der er den
slags forbindelser, ja så udnytter jeg dem nok ikke...

> Kender du andre, der benytter MSSQL på webhotellet? - Hvad siger de: Er
> det mon simpelthen en langsom MSSQL-installation, de har?

Desværre, kender jeg ikke andre (scannet.dk).

> At afvikle queries som stored procedures betyder ikke nødvendigvis
> højere hastighed.

Øv - jeg var sikker på at det var den vej jeg skulle gå...

> Der er mange standard SQL features, som MySQL ikke understøtter, så ja,
> nogle gange er konverteringen besværlig. Er PostgreSQL en option på dit
> webhotel?

Desværre er PostgreSQL ikke en option på mit webhotel.

Venlig hilsen
Lars





Troels Arvin (30-03-2003)
Kommentar
Fra : Troels Arvin


Dato : 30-03-03 18:17

On Sun, 30 Mar 2003 17:43:42 +0200, Lars Aagaard wrote:

>> Er det store datamængder (== store tabeller)? - I så fald: Har du
>> kigget på, om dine tabeller er indekseret korrekt?
>
> Jeg det er store datamængder, og mit kendskab til indeksering er
> begrænset, så det muligt at problemet ligger her....

Hvis du ikke har tjek på indeksering, så få det! Korrekt
indeksering i din database er ofte den mest effektfulde optimering, du kan
lære dig. En meget grov beskrivelse:

1) Sæt hellere et index for meget på end ét for lidt.

2) Indeksér kolonner, som du kan se, at DBMS'et er nødt til at søge
igennem - fx. dem der indgår i WHERE-udtryk. Primærnøgler behøver
ikke et eksplicit index - de er implicit indekseret (gad vist om dette
er en universel sandhed?)

Grundig indeksering kan kræve, at du har adgang til at få analyseret
dine queries. I andre databasesystemer gøres det ofte vha "EXPLAIN"
statements; med MSSQL kunne man forestille sig, at det sker på anden vis;
det er der garanteret en MS SQL wizard her i gruppen, der ved. Desuden
findes der garanteret noget online dokumentation fra Microsoft ang. dette.

Der er tonsvis af materiale om indeksering. Blot ét eksempel:
http://techdocs.postgresql.org/techdocs/pgsqladventuresep2.php (Emnet
burde være ret produktuafhængigt.)

> Det er min fornemmelse at det er connect-tiden, som er blevet meget
> langsommere
Det kan du garanteret kode dig frem til et svar på. Jeg kender ikke så
meget til ASP, men jeg kunne forestille mig, at du har mulighed for at
registrere

1. tidspunkt lige før forbindelse oprettes.

2. tidspunkt lige efter forbindelse er oprettet.

3. tidspunkt lige før query er sendt.

4. tidspunkt når result set begynder at strømme ind

5. tidspunkt når result set er indhentet

Hvis tidspunktet 1-2 dominerer, så bruger du bedst din tid på at
undersøge, om du har mulighed for at benytte persistente DB-forbindelser
i din web-applikation. Det må din udbyder kunne hjælpe dig med, om ikke
andet.

/Troels

Nikolaj Hansen (06-04-2003)
Kommentar
Fra : Nikolaj Hansen


Dato : 06-04-03 03:06

> 1) Sæt hellere et index for meget på end ét for lidt.

Ikke helt enig

Du skal have en rimelig selektivitet på dine data i den kollonne du
indexerer, ellers kan det faktisk gå langsommere end et full table scan. Et
eksempel kan være en boolean kolonne, hvor du har 50/50 true og false. Her
skal du under alle omstændigheder halvdelen af rækkerne igennem i snit, med
eller uden index.

Alle dine DML'ere kommer til at køre væsentligt langsommere, hvis du skal
opdatere indexerede kollonner. Self. fordi indexes også skal opdateres.

Så hvis man har meget få ændringer i data, så har du ret. Hvis man har mange
ændringer i data kan det koste dyrt at have ubrugte indexes liggende.



Lars Dybdahl (06-04-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 06-04-03 08:16

Troels Arvin wrote:
> Hvis du ikke har tjek på indeksering, så få det! Korrekt

Enig.

> 1) Sæt hellere et index for meget på end ét for lidt.

Bortset fra en en index for meget også sløver databasen, men da en for lidt
sløver mere, er jeg enig.

> 2) Indeksér kolonner, som du kan se, at DBMS'et er nødt til at søge
> igennem - fx. dem der indgår i WHERE-udtryk.

Du mangler:

3) ORDER BY bruger også indexes. Normalt skal man indexere alle
kombinationer af ORDER BY og WHERE, og nogle gange også i begge retninger,
hvis man vil sammenligne (< og >) eller sortere i begge retninger.

4) Sørg for at de rette indexes bliver brugt i SQL statements.

>> Det er min fornemmelse at det er connect-tiden, som er blevet meget
>> langsommere
> Det kan du garanteret kode dig frem til et svar på.

Jep - i php har man f.eks. "database_pconnect" funktionerne til at undgå, at
der forbindes fra hvert script.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

Ole (07-04-2003)
Kommentar
Fra : Ole


Dato : 07-04-03 07:52


"Lars Aagaard" <lars@123nu.dk> skrev i en meddelelse
news:b673d3$2eei$1@news.cybercity.dk...
> Hej Troels,
>
> Tak for svaret.
>
> > Er det store datamængder (== store tabeller)? - I så fald: Har du kigget
> > på, om dine tabeller er indekseret korrekt?
>
> Jeg det er store datamængder, og mit kendskab til indeksering er
begrænset,
> så det muligt at problemet ligger her....
>
Lad os få defineret hvad store datamængder er:
Antal tabeller
antal felter pr tabel
antal poster pr tabel

> Desværre, kender jeg ikke andre (scannet.dk).
Jeg har selv gode erfaringer med Sql-server ("komplet" webhotel) hos
scannet.dk


mvh

Ole



Lars Dybdahl (30-03-2003)
Kommentar
Fra : Lars Dybdahl


Dato : 30-03-03 23:40

Lars Aagaard wrote:
> Jeg har netop konverteret min side fra Access til MS-SQL.

Sidst jeg skulle lave et program til begge systemer, fandt jeg ud af, at der
var gigantisk forskel på, hvad der kørte hurtigt på de to systemer. F.eks.
er dette noget af det hurtigste man kan lave på MS Access:

select * from tabel

hvorimod det er noget af det dummeste man kan gøre på MS SQL server. Her bør
man til gengæld angive feltnavne osv.

Da jeg skulle lave et system, der kunne køre på begge databaser, samt
Oracle, og skulle have optimal performance på alle tre, lavede jeg et
programmodul, som opbyggede SQL statements ud fra et API. Resultatet var
gigantiske SQL statements til MS SQL server, ofte over 10kbyte bare for
selve SQL kommandoen, men performance var extrem god. På MS Access var de
samme SQL statements væsentligt mindre, men også hurtige. Oracle og MS SQL
server skulle have tingene meget forskelligt - den ene brugte joins og den
anden gjorde ikke osv.

Generelt skal du:

1) Have de rigtige indexes.
2) Sørg for, at MS SQL serveren rent faktisk bruger de tiltænkte indexes.
Alt for ofte har jeg set, at folk hælder masser af indexes i en database,
men at databasen så enten vælger det forkerte index, eller prøver at flette
to indexes, hvilket selvflg. begge giver ekstrem dårlig performance.
3) Tilpasse dine SQL statements til, hvad database systemet bedst kan lide.

Et typisk problem er, hvis folk har to tabeller, postnumre og personer, og
vil have en adresseliste over alle personer i Roskilde sorteret efter navn:

select personer.navn,personer.adresse,personer.postnr,postnumre.postdistrikt
from personer inner join postnumre on personer.postnr=postnumre.postnr
where postnumre.postdistrikt='Roskilde'
order by navn

Denne SQL er jo helt hen i vejret, eftersom at både where-delen og
order-delen har brug for indexes, men går på data i hver sin tabel. Man kan
ikke få en god performance på denne SQL statement uanset hvor mange indexes
man hælder i sin database. Resultatet i ovenstående tilfælde er en af
følgende:

1) Udvælg på postnr i stedet for postdistrikt. Da postnr findes i personer
tabellen, kan man så lave et indeks på tabellen personer med felterne
postnr og navn.
2) Lav et felt i personer tabellen, der hedder postdistrikt. Og ja, det er
redundant data, og ikke særligt normaliseret, men kunden bliver ofte
gladere for et system med lave svartider end et system der er normaliseret
og uanvendeligt.

P.S.: jeg ved godt, at visse database systemer kan lave indexes på tværs af
tabeller, men det synes jeg ligger uden for emnet.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste