ms sql 2005 + mediator - czemu to tak strasznei wolno chodzi?
pabi - 22-11-2006 00:03
ms sql 2005 + mediator - czemu to tak strasznei wolno chodzi?
Dzien dobry
Mam program poznańskiej firmy i pracuje on na MS SQL 2005 za posrednictwem
mediatora. Bazy sa po prostu jako tabele, nie powiązane relacjami.Wszystko jest
zaszyte w programie, chyba w harborze a posredniczy w komunikacji z sql
sewrerem program mediator. Czy ktos moze mi powiedziec czemu to tak strasznei
wolno chodzi i czego to wina i cyz da się to jakos przyspieszyc?
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Marek Horodyski - 14-12-2006 16:08
U?ytkownik "pabi" <pabi@autograf.pl> napisa? w wiadomo?ci
news:1b66.00000020.4562aca8@newsgate.onet.pl...
> Dzien dobry
> Mam program pozna?skiej firmy i pracuje on na MS SQL 2005 za posrednictwem
> mediatora. Bazy sa po prostu jako tabele, nie powi?zane relacjami.Wszystko
> jest
> zaszyte w programie, chyba w harborze a posredniczy w komunikacji z sql
> sewrerem program mediator. Czy ktos moze mi powiedziec czemu to tak
> strasznei
> wolno chodzi i czego to wina i cyz da si? to jakos przyspieszyc?
Pewnie tak - ale producent musi duzo zmienic w aplikacji.
Proste przeniesienie aplikacji z DBF na jakis RDBMS spowoduje kilkukrotne
spowolnienie aplikacji w stosunku do tego co bylo na DBFach (). Na
dziendobry powinno sie mimowszystko zauwazyc poprawe stabilnosci. W sumie
aby uzyskac zauwazalny wzrost wydajnosci nalezy postawic jakiego smoka jako
serwer bazy danych i Mediatora. To i tak nie pozwoli na osiagniecie
szybkosci pracy z DBFami, ale powinnismy juz miec spokoj z rozwalonymi
danymi (chociaz tu chyba lepszym rozwiazaniem bylo by patchowanie novela).
Pozniej przejsc z Clippera na [x]Harbour - tu wyraznie widac lepsze/szybsze
wspolgranie aplikacji. No a dalej to juz trzeba analizowac model danych, i
albo go zmieniac jednoczesnie przechodzac na SQLa, albo w zapytaniach bardzo
dokladnie uwzgledniac to co zrobil mediator. Osobiscie wybralem ta 2 metode
(jednoczesnie ograniczajac gdzie tylko sie dalo zakladanie zlonych kluczy
indeksowych), gdyz nawet jak nie osiagne wydajnosci pierwszego rozwiazania,
to pozwala to na mieszanie technik, prawie ze az do bolu. Zapytania
wygladaja troche dziwnie, stosuje " ie$1 LIKE ID||% " itp. rozwiazania, ale
wiem ze nawet jak to jest LIKE to oprze sie o indeks bo nie ma wiekszej
mozliwosci, a przyspieszenie moze byc ogromne. Dosc powiedziedziec, ze
ciezkie zestawienia ktore na DBFach dopiescilem na amen, i na
notebuku/lokalnie/DBFy trwaly ponizej 4s., poprzez mediatora w srodowisku
produkcyjnym trwaly do 4h. Zapuszczenie tego na DBFach w sieci (prawdziwe
blokady jednak trwaja!) mimowszystko wydluzalo czas do kilku, moze
kilkunastu minut w skrajnym przypadku. Do tego nakladaly sie bledy zalozen
analitycznych, obchodzone rzutem na tasme - kosztem okolo 1000 krotnego
zwiekszenia ruchu na sieci. Ale stopniowa optymalizacja, przenoszenie logiki
na sqla a tym samym na serwer bazodanowy (np. grupowanie) pozwolilo zesc z
tych 4h do jakich 4min - co juz jest akceptowalne. A i tak wiem jak to
jeszcze conajmniej 2-3 krotnie przyspieszyc, tylko na to potrzeba czasu, a z
nim jest naprawde cienko. Tak ze droga jest dobra, tylko nie mozna
poprzestac na pierwszym kroku - trzeba isc dalej. Teraz, nawet do celow
komercyjnych chyba wszystkie firmy wypuscily swoje freewerowe wersje RDBMS.
Serwery te, pomimo ograniczen sa wystarczajaco dobre dla wiekszosci firm o
zasiegu lokalnym, tak ze z tym nie powinno byc wiekszego problemu. Tak ze
mozna pocwiczyc z roznymi bazami danych.
Mediator to fajna rzecz, ale trzeba myslec po SQLowemu. Na stacji nie trzeba
miec klieta bazy danych - a pracuje sie tak jakby on tam byl. Tylko serwer
Mediatora musi miec takiego klienta. Dodatkowo wspiera logike xBasowa, ktora
wcalae nie jest zla - tylko trzeba to wszystko ladnie pozenic, wybierac
najlepsze rozwiazania z kazdej z technologii :).
Pozdrawiam,
Marek Horodyski
pwola - 14-12-2006 16:08
>> Czy ktos moze mi powiedziec czemu to tak
>> strasznei
>> wolno chodzi i czego to wina i cyz da si? to jakos przyspieszyc?
>
>Pewnie tak - ale producent musi duzo zmienic w aplikacji.
>Proste przeniesienie aplikacji z DBF na jakis RDBMS spowoduje kilkukrotne
>spowolnienie aplikacji w stosunku do tego co bylo na DBFach ().
Kilkukrotne spowolnienie to mo?e nie...., zale?y jaka aplikacja i jak
mierzy? :-)
Faktycznie porównuj?c wydajno?? na systemie aplikacji na której
pracowa?o kilkudziesi?ciu u?ytkowników w aplikacji Clipper *.dbf na
NetWare 4.1 do uk?adu Mediator - Oracle (na ró?nych maszynach) to
wydajno?? by?a porównywalna zw?aszcza dla tabel które mia?y kilka
milionów rekordów i ponad 1 GB - fakt Oracle pracowa? na 4
procesorowym serwerze :-) .
Append rekordów na Oracle by? troch? wolniejszy (mówi? ca?y czas do
pracy na sieci, bo lokalnie to dbf-y zawsze by?y szybsze :-)
ale za to select by? wydajniejszy.
W sumie po przeniesieniu aplikacji na uk?ad Mediator - Oracle
aplikacje zyska?y na wydajno?ci i sko?czy?y si? godzinne przestoje na
odbudow? indeksów i usuwanie awarii danych.
To co stanowi problem wydajno?ci wi?kszo?ci aplikacji szczególnie tych
pisanych w Clipperze to raportowanie z du?ych baz danych - w ko?cu
wszystkie rekordy trzeba przepchn?? do stacji klienta i przetworzy? a
to musi bole? :-)
Mo?liwe rozwi?zania:
1. Przepisa? raporty na sterownik MEDSQL (uda?o mi si? skróci? w ten
sposób czas z kilku godzin do kilku minut - ale to chyba dzia?a tylko
z Oracle)
2. Wykonywa? raporty bezpo?rednio z bazy danych zewn?trznym narz?dziem
np. SQLPlus, PHP, Oracle Reports, Crystal Reports, Delphi, C
ostatecznie mo?na podpi?? si? nawet Accessem
W?a?ciwie to problemem jest fakt przetwarzania danych na stacjach
roboczych, a nie na serwerze i te dane trzeba przez sie? przepchn??.
Paradoksalnie szybsza sie? mo?e spowodowa? ogólny spadek wydajno?ci
aplikacji, bo klient coraz szybciej ??da danych
a serwer.....
"nie ma.... nie ma... mo?e pó?niej... nie ma... "
i op?dzaj?c si? od obs?ugi ??da? nie ma czasu na wystawienie danych
:-)
Sensownym rozwi?zaniem wydaje si? przeniesienie przetwarzania danych
tak blisko danych (w sensie szeroko?ci kana?u transmisji) jak to
mo?liwe czyli zatrudnienie serwera bazy danych do przetwarzania i
obrabianie danych zagregowanych
Ale to tyle teorii teraz troch? praktyki :-)
Czy sprawdzi?e? gdzie masz "w?skie gard?a"
Porady dotycz? co prawda Oracle ale mam nadziej?, ?e MS SQLwygl?da
podobnie :-)
Jak z wydajno?ci? bazy danych? Czy problemem jest 100 % obci?zenia na
procesy obs?ugi bazy danych ?
Jak skonfigurowana jest baza (na ilu dyskach) ?
Jaki transfer z dysków ?
Czy ma dostateczn? ilo?? pami?ci?
Je?eli tu jest problem to mo?e pora pomy?le? o nowej maszynie :-)
Mediator'a mo?na postawi? na inn? maszyn? ( z tego co pamietam to w
statystykach mia? do 20% czasu procesora)
Aha... i mo?e najwa?niejsze nie próbuj poprawia? wydajno?ci w??czaj?c
cachowanie zapisów na stacjach !!!
Piotr
Marek Horodyski - 14-12-2006 16:08
U?ytkownik "pwola" <pwola@polbox.com> napisa? w wiadomo?ci
news:5samm256ctl716m4g09mdmhoop6oooorc3@4ax.com...
>>> Czy ktos moze mi powiedziec czemu to tak
>>> strasznei
>>> wolno chodzi i czego to wina i cyz da si? to jakos przyspieszyc?
>>
[...]
> milionów rekordów i ponad 1 GB - fakt Oracle pracowa? na 4
> procesorowym serwerze :-) .
Pisalem o smokach :) Chociaz 4 to nic, 64 to juz cos, a 128 ...
W kazdym badz razie jak ktos zmieni na maszynie NetWare na jakiegos RDBMS to
sie srodze zawiedzie.
Maszyna musi byc znacznie silniejsza, i jak serwer sie rozbuduje - efekty
daje sie zauwazyc.
> aplikacje zyska?y na wydajno?ci i sko?czy?y si? godzinne przestoje na
> odbudow? indeksów i usuwanie awarii danych.
Zauwazylem, ze na wydajnosci zyskuja aplikacje o niepowiazanych tabelach.
Jak aplikacja uzywa xBasowych relacji, zmienia je w trakcie pracy itp. to
zauwaza sie duzy spadek wydajnosci.
Ale znowu zrezygnowac z tego ciezko, bo to zdejmuje iles z programisty.
Dlatego pisze o mieszaniu rozwiazan.
> To co stanowi problem wydajno?ci wi?kszo?ci aplikacji szczególnie tych
> pisanych w Clipperze to raportowanie z du?ych baz danych - w ko?cu
> wszystkie rekordy trzeba przepchn?? do stacji klienta i przetworzy? a
> to musi bole? :-)
Ale jak sie uzywa dbEvale, dbJoiny, dbCopy, indeksy miejscowe,
ascending/descending, z klauzulami for i while - duze bazy przestaja bolec.
Najgorsze sa te uszkodzenia danych. Ale popatchowany serwer ponoc sie
poprawnie zachowuje.
> Mo?liwe rozwi?zania:
> 1. Przepisa? raporty na sterownik MEDSQL (uda?o mi si? skróci? w ten
> sposób czas z kilku godzin do kilku minut - ale to chyba dzia?a tylko
> z Oracle)
MedSql itp. nie sa rozwijane. Standardowy DBFNTX zaspokaja wszelkie
potrzeby. Generalnie trzba tylko otwierac dane poprawnie spreparowanymi
zapytaniami.
Chodzi jak burza, tylko trzeba miec dobrze indeksy poustawiane (no i ten
SMOK :). Zawsze klania sie poprawnosc modelu danych.
> 2. Wykonywa? raporty bezpo?rednio z bazy danych zewn?trznym narz?dziem
> np. SQLPlus, PHP, Oracle Reports, Crystal Reports, Delphi, C
> ostatecznie mo?na podpi?? si? nawet Accessem
Jak aplikacja elastyczna, to ni? si? zrobi duzo wiecej niz generatorem
zewnetrznym.
> W?a?ciwie to problemem jest fakt przetwarzania danych na stacjach
> roboczych, a nie na serwerze i te dane trzeba przez sie? przepchn??.
> Paradoksalnie szybsza sie? mo?e spowodowa? ogólny spadek wydajno?ci
> aplikacji, bo klient coraz szybciej ??da danych
> a serwer.....
> "nie ma.... nie ma... mo?e pó?niej... nie ma... "
> i op?dzaj?c si? od obs?ugi ??da? nie ma czasu na wystawienie danych
> :-)
Tak wlasnie jest. Trzeba przechodzic na SQLa, laczyc i grupowac po stronie
serwera.
Wczesniej jakies przetwarzania setek tysiecy rekordow, kilkanascie/dziesiat
tabel, mieszanie tam i spowrtotem -
a tu czesto wystarczy jedno zapytanie i ma sie odpowiedz po 5 - 15
sekundach - na poczatku przezywalem maly szok.
Dlatego uwazam ze oprogramowujac bazy sqlowe pisze sie prosciej - mniejsze
szanse na zaciecie przy goleniu :)
Pozdrawiam,
Marek Horodyski
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
jak to =?ISO-8859-2?Q?zrobi=E6=2E=2E=2E=3F_TSQL_sql_server?==?ISO-8859-2?Q?_?=
=?iso-8859-2?Q?=5BMS_SQL=5D_Czy_mo=BFna_wywo=B3a=E6_funkcje_t ylko_raz_dla?==?iso-8859-2?Q?_ca=B3ego_zbioru_=BCr=F3d=B3owego=3F?=
[MSSQL] =?ISO-8859-2?Q?zgodno=B6ci_z_licencjami_Microsoft_?==?ISO-8859-2?Q?SQL_Server?=
Oracle PL/SQL Wstawianie =?ISO-8859-2?Q?wynik=F3w_kolekcji_d?==?ISO-8859-2?Q?o_tabeli?=
[MSSQL] ACCESS - SQL =?ISO-8859-2?Q?B=B3ad_w_konwersji_lic?==?ISO-8859-2?Q?zb?=
=?iso-8859-2?Q?=5Bmssql=5D_Zapytania_rekurencyjne__-_czy_sk=B3adnia_sql?==?iso-8859-2?Q?_co=B6_takiego_przewiduje_=3F?=
[Oracle PL/SQL] Cursor i zapis =?ISO-8859-2?Q?rekord=F3w_do_?==?ISO-8859-2?Q?kolejnych_plik=F3w?=
=?iso-8859-2?Q?=5BMySQL=5D_Co_minimalnie_potrzebne_zeby_mie=E 6_klienta_My?==?iso-8859-2?Q?SQL_na_Linuxie=3F?=
[oracle] - Oracle SQL Developer - co to jest SID?
=?ISO-8859-2?Q?[Oracle]_Wywo=B3anie_skryptu_sh_z_PL/SQL-a=3F=3F?=
zanotowane.pldoc.pisz.plpdf.pisz.plptsite.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
