Helios Green aneb nejsprasenejsi aplikace kterou znam

[Doktor-Prase]

ROFL. V Catii je "Press OK to terminate" a jediny co muze clovek udelat, je zmacknout v messageboxu OK a tim si odstrelit CATII, v nejlepsim pripade po x-hodinach neukladani

[mugsat]

Mno, tisky sou trošku problematicky jinak co se týče Object not set to an instance... nevím jak víte moc o programování, ale je to typicka hlaska kdyz zapomenete zinicializovat promenou, nebo nacitate null hodnotu atd

[D_a_v_i_d]

Mno, tisky sou trošku problematicky jinak co se týče Object not set to an instance... nevím jak víte moc o programování, ale je to typicka hlaska kdyz zapomenete zinicializovat promenou, nebo nacitate null hodnotu atd

Ale jo, vím co to "obecně znamená", v tomhle případě bych to pochopil, pointa byla v tom, že to bylo v první verzi prostředí, ve které implementujeme uživatelská nastavení (tj. jde už spíš o "klikačku" než vlastní programování), a byla tehdá ještě dost zabugovaná, takže člověk kolikrát nevěděl, kde všude musí co udělat, aby se vše inicializovalo. Díky bohu, už jsem tuhle hlášku tak rok neviděl... Nejlepší bylo, když člověk nějakou delší dobu něco nastavoval, pak to vyplivlo toto a prostředí se dostalo do "nedefinovaného stavu", kdy ho člověk radši restartoval, protože nikdy nebylo jisté, co se z rozdělané práce reálně uloží a co ne

[Jezevec]

Tak pánové....
pro Vás rádoby chytrálky.

1) pole máte za barákem, to co nazýváte polem je atribut. ANO, uživatelský (UDA) atribut, který zakládáte Vy nemůže mít ve slově postfix "_nazev" ani "_refer", a to protoze se dynamicky zpracovavaji formuláře a tyto postfixy automaticky určují, že se jedná o vztah.
2) ad servicegate.asmx -> to webové rozhraní, jak vy píšete o tom že někdy něco zůstane někdy ne - je to jednoduché... zpracovává se to transakčně. Předpokládám že mluvíte o funkcionalite INSERT/UPDATE volání, kde se zpracovávají jednotlivé záznamy jakožto samostatné tranasakce.
3) k návrhu databáze - je dovolím si říct ve standardu slušně optimalizována. Je implementováno x desítek společností, kde pracuje naráz více jak sto uživatelů a není zaznamenáno problémů. Možná je problém v implementaci od partnerske firmy.


Howgh....

Jiste, databaze je tak uzasne optimalizovana, ze nad ni nemuze pracovat 30 lidi zaroven (by default samo) bez toho, aniz by se navzajem vsichni zablokovali. A dodavatel ma tak uzasne vyvojare a databazisty, ze to ani za penize nejsou schopni vyresit. A to podotykam, ze se nebavime o desitkach ani stovkach tisic.

Jiste, moje optimalizace byla jiste naprosto zbytecna, zajimave ze bez ni novy uzasny .NET nejede vubec.

Ad nazvy poli, taky uzasna funkcionalita, kdyz se pole jmenuje jinak na formulari a jinak ve filtru, ze ? Aha, ja zapomel ze je to featura (a podotykam, ze nemluvim o uzivatelskych formularich). Dalsi uzasna featura je, ze by default vsichni muzou vsechno, a jakmile se objevi nejaka nova vec, tak ji admin musi vycuchat a zakazat (protoze jinak se useri dostanou klido k vejplatam ...). Jo, abych nezapomel, na dynamicky vztahy pro jistotu prava nastavovat nejde vubec, taky dobry, ne?

Apropos, napada vas nejaky duvod proc se 10 000 zaznamu v logu maze hodinu? To bude jiste tim dokonalym navrhem databaze.

Ad grid, by default se nacita 30 zaznamu, a pak se, kdyz je monitor dost velky, nenaplni ani okno a neukazou se ani rolovaci listy (ja vim, uzasna featura) takze kazdy normalni uzivatel zije v domeni, ze uz toho tam vic neni ( jo, ja vim uzasna vec ze tam je pocet v zahlavi, tam to urcite kazdej hleda ). Mimochodem PB verze byla 10x rychlejsi ve vsech ohledech. A nechapu proc si nemuzu odrolovat 100 000 zaznamu, kdyz v blbym excelu si jich odroluji klidne mega za par vterin. Jen pro zajimavost, udelal sem si grid, prasknul do nej query nacitajici hlavicky dokladu, a ono to naprosto vpohode rolovalo stejne jako kazda normalni aplikace => statisice zaznamu behem par vterin. Prgani (teda spis kliknani) na 10 minut prace.

Ad chyby, buton odeslat adminovi je naprosto k hovnu, protoze se z nej (z toho hlaseni) jakozto admin ani nedovim co ten uzivatel delal. Takze stejne potrebuju aby mi to napsal nebo tipnul screen. Jiste dalsi uzasna featura.

Ad dialogy, vazne mam najit ta min 3+ let stara hlaseni, ze se zobrazuji okna dotazu za formulari ? Stale nevyreseno. Neumi to ani takovou trivialni vec, aby okno prihlaseni melo focus. Ano, mluvim o tom co se pusti po stlatecni ikony, kazdej blbej soft ma fokus, jen na tohle se musi jeste kliknout.

patche (sem zvedav kde mate tech 20MB):
42.30 - 105MB
42.30.40 - 91MB
42.33 - 113MB
42.33.10 - 96MB

(pro ty co netusi, tak bez tretiho cisla je to patch, s nim "hotpatch", to posledni je prvni uprave te 33 => nebali to na sebe predchozi => ten 20MB maximalne velky hotpach v realu ani vzniknout nemuze, to muze byt tak maximalne quickbuild => zakaznikem vyrvana oprava vuci jeho patchsetu, ale to je proste neco, co se standardne nevydava)

2Marty: Jo, ono to funguje - uz, oni nejak pani v LCS zapomeli v dokumentaci zminit, ze neumeji tisknout na sitovou tiskarnu, ale ze musi by nainstalovana jako lokalni. Takova drobnost co se resila tusim 3 nebo 4 mesice.

BTW: Pro vasi informaci, nekde se mi tu povaluje ten vami zminovany certifikat, to skoleni je taky uzasna vec, na ktery se clovek nic nedozvi. Ze vsech, ktery jsem absolvoval stalo za rec jediny, ktery skolil nejakej ranenej vyvojar, to ostatni bylo predcitani pripravenych plku. Jo, vubec nejlepsi bylo kdyz skolitelka zjistila, ze "ono to nefunguje tak jak rika (na moje upozorneni)" a mlela vesele dal.

----
Mimochodem, celkem nedavno sem prisel na novou featuru, kdysi slo nad prilohama zmenit zpusob ukladani do databaze a poradac vesele dal fungoval, jen nove soubory ladoval do novehoho uloziste a ty stare normalne oteviral z disku. Nevim se kterym patchem, ale prestalo to fungovat a na dotaz se mi dostalo uzasne dlouhe odpovedi uplne o hovne (a o necem jako hromadnym presunu tech souboru, si muzu nechat leda zdat, pricemz i tohle prasteny forum to umi).

Edit: Pro zajimavost, rad bych jedineho zakaznika (opravdu mi staci jeden jediny), ktery mi rekne do oci, ze je se system spokojen. Nikoho takoveho nam LCS nebyla schopna dodat. Kdykoli sme nekam jeli se podivat na nejake reseni (predevsim ohledne migrace) tak se zjistilo, ze to byl jeden velkej pruser.

[mugsat]

tak popořadě... jezevčáku vidíš to moc černě.

30lidí nad tou databází může pracovat naprosto s přehledem, aniž by se navzájem blokovali, SAMOZREJME... pokud spustíš nápočty skladových uzávěrek, je logický, že kvůli konzistenci dat se musí záznamy které se načítají zamknout... nikdo ti nezakazuje dtb replikovat a takovéhle operace provádět mimo... Pokud se ti to zamyká více, bylo by vhodné zjistit příčinu ( např z logu blokování ... )


Co se týče tvoji optimalizace, tak pokud sis přidal své indexy, může to být pokud se v tom vyznáš dozajista výkonově lépe natom, než indexy, které generuje systém při zakládání uziv. trid...

Default muzou vsichni vsechno... co k tomu dodat,... nastav si defaultni skupinu tak aby nemohla nic ale to neni vada systemu, kdyz nastavis ve windows práva na disk pro everyone na všechno, tak každý nový uživatel taky bude mít práva... tak se nad tim zamysli proboha.

Ad jména na formuláři a filtru... - co na to proboha říct? POle se jmenuje pokaždý jinak, jen tam máš jiný label pravděpodobně. Nevím jestli to je zakázkový formulář, nebo to je v defaultnim modulu, ale vzdy mas moznost ctrl + shift + d si zjistit přesný název pole, pokud ti to neni jasny od pohledu... A uzivatelsky formulare myslim nema cenu rozebirat, kdyz si je muze upravit kazdej jouda ze?

Ad datamining co tu byl zminovanej, vyzkoušel jsem využít toho výrazu, jak jsi říkal, a nepodařilo se mi nasimulovat. Udej prosim příklad.

Proč se 10 000záznamů maže hodinu? Protože se hlídá konzistence dat ... jestli ti to něco říká kontroluje se, zdali neni zaznam navazany ve vztazích, případně nepovolí záznam smazat, pokud na něj něco ukazuje. Pokud si navrhl systém, kde se tohle nehlídá, gratuluji, můžeš ho smazat

ad grid -> proboha, nastav si počet načítanejch záznamů sám a optimálně podle sebe. Jinak tady je nejaky fail, tohle scrolování se mi taky nelíbí.

Ad dialogy -> hlásil si ty chyby?

Ad focus : zadej to jako iou požadavek, určitě ti za nějaký obnos asseco vyhoví

ad tiskárna - https://forum.helios.eu/green/doc/cs...u_PrintRequest - oddíl 2. -> tiskárna musí být na aplikačním serveru. -> méně stěžování na fóru -> více hledání na dokument. portálu / zavolat na hotline a bude ti veseleji


ad externí soubory -> ve verzi 43 došlo ke změně práce s externími soubory taktéž bych doporučil manuál

https://forum.helios.eu/green/doc/cs..._-_manu%C3%A1l

Bohužel z mojí pozice nemohu mluvit o klientele, ale obecně mohu říci že například. vodárenské společnosti s heliosem jsou v celku spokojeny.

[Jezevec]

a) ad pocet uzivatelu a blokovani, mno LCS to resila 2 roky? (Marty?) a nevyresili NIC. Za optimalizovanou rozhodne nepovazuju databazi, kde jsem schopen jako administrator dosahnout vic nez desetinasobnyho zrychleni, tomu se totiz nerika optimalizace, ale sprasena aplikace. Vubec nemluve o HW pozadavcich, pro prislusny pocet uzivatelu, mame (dle pozadavku LCS) min 100x predimezovany HW(to sem zaridil tak trochu i osobne) a stejne to jede jak kdyz se.e a maluje (na HW dle specifikace by se to nedalo provozovat, coz nam potvrdilo nekolik zakazniku, kteri naivne uverili).

b) ad prava, rad bych, ale to by to muselo fungovat (nekolikanasobna zkusenost).

c) Sorry, ale kazda normalni aplikace si bere viditelny nazev z nejaky prekladovy tabulky, a zobrazuje ho vsude a vazne chci videt, jak budu chudakum uzivatelum vysvetlovat, ze to co videj na formulari nenajdou v seznamu poli ve filtru a ze si maj nejdriv zjistovat jak ze se to ve skutecnosti jmenuje. O tom, ze to je tak jako tak bordel (uzasna vec, kdyz to neni razeny abecedne, ale podle typu, kterej je omarkovanej nejakym pidiznakem a navic v tom nejde hledat) ani nemluve.

d) ad mazani, znaji v LCS neco jako cizi klice? Podle vseho neznaji, uzasne sledovat jakym zpusobem (napr) mazou data. Konzistenci dat ma zajistovat databaze, a ne aplikace. Nemluve o tom ze mluvim o LOGu!, tedy nic, co by stalo z pohledu dat za rec + tu sou od toho transakce. A ad konzistence dat, uz se LCS naucila zaridit UNIKATNI cisla dokladu? Pokud vim, stav je jiz nekolik let takovy, ze doklady (celkem bezne) maji obcas stejna cisla. Pri nasem mnoztvi jich sem schopen najit tak 10 do mesice - opet opakovane reportovana (a zdaleka nejen nami) chyba, kterou jaksi neumi vyresit. Vubec nemluve o uzasnem systemu generovani noveho cisla dokladu pohledem do databaze na posledni existujici => pokud udelam fakturu, a nasledne ji smazu, tak dalsi faktura bude mit stejny cislo (plati obecne o vsech dokladech), fakt uzasny.

e) hlasil sem tolik chyb ktery nikdo nevyresil, ze to uz ani neresim, stejne jako vsichni ostatni admini a ne, opravdu nehodlam ani premyslet o placeni za opravy CHYB.

f) ad tiskarna, kde tam je, ze ma byt lokalni? Kdyz primontuju sitovou tak v ramci aplikacniho serveru existuje, kazda jina aplikace na ni bude tisknout. Ostatne tisk je vubec kategorie sama pro sebe, kolik ze tam je tech tlackatek, 7? A ani lidi z LCS nedokazou vysvetlit, jakej je mezi nima rozdil.

BTW: Vodarny, ty asi nemaj 20 000 polozek ve skladu co? Ta jedna co tam maj ta to opravdu nevytrhne.

Nejvic me pobavily ty plky pri prechodu z PB na NET, ze je to jen patch na odpoledne, a ze to vykonostne bude pry dokonce lepsi nez PB ... ... pripadne predstava LCS o tom, co to je tenky klient (ma to 200MB, to je fakt klientik do mobilu jak kdyz fikne) ... pripadne 3stupnova architektura (min 1/2 logiky neresi aplikacni server, ale klient + SQL scripty) a taky me bavi, jak chudak nas partner pres podporu musi bastlit do DB vsemozne triggery a updatovat natvrdo do databaze, aby zajistil pozadovanou funcionalitu.

Vysledek prechodu na NET byl ten, ze vykon spadnul zhruba 10x a bez toho co jsem v DB udelal by se to nedalo pouzivat vubec (napr takove pridani polozky na poptavku trvalo cca 2 minuty - optimalizovana databaze od LCS).

---
Jen tak jeste hodne pod carou:
Pozadavek: Potvrzeni funkcionality na SQL 2k5 (provoz na 2k)
Vyjadreni: No mi to na tom mame a funguje nam to ...
Vysledek (po testovacim prevodu): No ono je treba x, y,z, .... a to vsechno bude trvat min celej den ... a jeste to nemusi dopadnout ...
Nekolik tydnu po prevodu ostre DB: No mi sme zjistili, ze stimhle nastavenim(vyse doporucenym jako jedinym moznym) nam nefunguje KLM, bylo by lepsi, kdyby ste to prevedli zpet (naprosto nerealne).

Predpokladam ze prechod na vyssi verze bude vypadat podobne - "si to nejak prevedte, ale taky vam to nemusi fungovat"
Ocekaval bych, ze u SW za par mega dostanu jednoznacny vyjadreni ve smyslu "ano, SQL 2k5 podporujeme, funkcionalitu garantujeme a je treba nasledujicich kroku:"
Stejne jako bych ocekaval, ze dodavatel je schopen rict, zda neco bude nebo nebude fungovat v nejake konfiguraci (ze to otestuje) a ne ze rekne "no mi to tak nemame, tak nevime".

[Marty]

Většina problémů HeG podle mého názoru pochází z toho, že jde o aplikaci koncepčně starou. Takových systémů jsou spousty, kde nejsou žádné relace, cizí klíče... Díky bože za aspoň za indexy a constrainty! HeG aspoň používá čísla subjektu v akceptovatelným formátu, takže s rozumným fillfactorem se dají postavit slušný clusterovaný indexy - výkon jde nahoru... nevim ale co je tam v defaultu, docela bych se na to po letech zas mrknul, kam se soudruzi posunuli.

BTW tenhle thread je na první stránce výsledků googla na dotaz "Helios Green"

[Jezevec]

Neposunulo se to vubec nikam, krome toho ze preklopili PB na .NET a pri ty prilezitosti zachovali vse co v PB stalo za kulovy a pribalili k tomu novy svinstvo v .NETu.

Napriklad nova featura NETu je, ze klient nemuze bezet trvale, anzto si pres noc restartujou IIS a on pak neumi reconect. Co je na tom jeste uzasnejsi, ze se neumi ani bez kecu ukoncit, navic se tvari, jako ze bezi.
Takze klasickej uzivatel prijde, vidi bezici aplikaci a klipne na poradac. Tam mu vyskoci info, ze aplikace zdechla Chciploto.jpg. Ovsem klient jako takovy dal bezi, s otevrenymi okny lze hybat, ale uz nereaguje na podnety tupu otevreni poradace (nijak). No a kdyz se klipne na krizek, tak se to jeste pro jistotu zepta, zda vazne ukoncit tu zdechlinu VazneUkoncitZdechlinu.jpg. Tohle musel psat chorej mozek.

Jak uz sem nekde vejs psal, narozdil od PB prisla dalsi featura a tou je, ze v prehledech (grid) nelze zobrazit vic nez 5000 zaznamu (natvrdo). Ono se neni moc cemu divit vzhledem ke zpusobum prace.

Jop, narozdil od 41, 42+ uz nema webovy rozhrani.

Nekde cestou od 41 taky zmizla moznost pouzivat kombinovane win/user-pass autentifikaci, ted se musis rozhodnout ze bud jedno nebo druhy.

Dalsi featura (mozna sem to sem uz taky psal) - telefonni cisla. Driv to bylo proste textovy policko, ted z toho udelali vztah. Jestli si pamatujes pruser ohledne DIC a evidence DIC, tak tohle je totez, akorat ve 100x vetsim rozsahu. Uzasny kdyz chces na organizaci zmenit nakou drobnost a ono ti to nejde ulozit, protoze mas v byvalem textovem poli neco jako "pan Voprsalek 0609123456", coz je sice z pohledu dat prasarna, ale daleko vetsi je menit pole v databazi z jednoho typu na jiny.

Co se tyce DB - bez jakekoli zmeny. Stale jedina centralni tabulka, do ktere se leze i tam, kde je to naprosto zbytecne.

[mugsat]

Nemuzu mluvit o přímém řešení, ani nevím z mého pohledu jestli vodárny sklad používají, ale pracují třeba s evidencí zařízení kde se pohybují řádově v statisících. Tak tu neplač nad 20 000.


Nevim o plcích k přechodu z pb->.net jestli to někdo sliboval tak chorý, protože migrace z pb to .net byla kapitola sama o sobě včetně všelijakých převodů reportů atd...


Pohybuju se v systemu zasilkovy sluzby, kde na skladě mame položek mnohem více než 20 000, a taktéž s výkonem problémy nějak nejsou, doporučuji rozdělit výkon na více strojů klidně méně výkonných ve farmě... nic jinyho ani nejde. A pokud máš jak říkáš spoustu logiky řešený triggerama... tak bych začal s problémem tam


Co se týče návodů atd na přechod na verzi 43, opět tě musím odkázat na dokumentační portál, člověče, čteš vůbec co ti píšu?

[paik]

klasika indie helpdesk

[Jezevec]

Mejme uzivatele HeG, ktery ma cca do 50ti skladovych polozek (nemluvim o mnoztvi skladem, ale o skladovych kartach). Onen uzivatel ma 5 prodavacek - zensky co sedej za stolem a prodavaji tech par polozek stale dokola. HeG neni schopen v zadne konfiguraci uspokojit pozadavek, aby prodavacka necekala na pridani polozky vice nez 1s (rozumny maximum). Proto ma onen zakaznik extrabur aplikaci, ktera nedela nic jinyho nez se laduje objednavky do extraburt tabulek a pres noc se to presype do HeG.

Samo to sebou nese i jiste dusledky - napriklad v prubehu dne nelze zjistit aktualni stav skladu (coz zakaznikovi sice vadi, ale neni to v jeho provozu nijak podstatne). HeG to proste neni schopen ruzmne rychle zvladat, o realizaci skladovych dokladu vubec nemluve.

---
Mejme jineho uzivatele, ktery pozaduje po systemu takovou trivialni vec, jako zauctovani faktury za bezneho provozu. Prakticky nelze. Zauctovani dokladu totiz zamkne sklad, pokud je na fakture vice nez nekolik malo polozek (do 5ti rekneme) tak trva jeji zauctovani i nekolik minut a po tu dobu nemuze prakticky nikdo nic (prijemky/vydejky/poptavky ... zkratka vse co pracuje se skladem).

Proto se faktury uctuji pres noc, coz sebou nese jiste dusledky ... napriklad nemoznost provozu 24/7
O akcich typu ucetni uzaverky a podobne ani nemluve, to se samo musi delat pres vikendy.

---
Mejme tretiho zakaznika LCS, ktery ma spoustu (jednotky tisic) zamestnancu, a jeho (celkem logicky) pozadavek zni, aby zamestnanci dostali vcas vyplaty. Pokud nekde cestou k nim nastane nejaka chyba, nerealizovatelne. Vypocet vyplat trva 3 dny v kuse. Schvalne, jak dlouho bude pocitat prumerne zrucna mzdova ucetni vyplatu rucne? 5 minut?. Takze 10 ucetnich by HeG spolehlive porazilo.

---
Opravdu mam rad, kdyz nekdo plka o clusteru, ktery HeG neumi pouzivat. HeG NENI schopen provozu s rozdelovanim zateze (a podotykam, ze toto je oficielni stanovisko LCS). Podotykam taktez, ze vykon HeG je prakticky naprosto nezavisly na vykonu HW, i kdyz budu aplikaci pouzivat uplne sam, bude to tragedie. HeG zaroven neumi pouzivat ani bezpecnostni cluster. Mimochodem, mame dva aplikacni servery (pro tech cca 30 lidi pracujicich zaroven) s parametry zhruba desetinasobnymi proti pozadavku LCS. O SQL se da rict, ze pozadavky prekracuje v soucasnosti min stonasobne.

Pro neznale: HeG neumi (vubec) pracovat na DB clusteru, dost pravdepodobne (vyjadreni LCS) nebude ani fungovat pokud si koupite maximalistickou licenci SQL s moznosti rozdeleni tabulek z duvodu paralelizace dotazu. M$ SQL prozmenu tak jako tak neumi vykonostni cluster - umi pouze cluster zabezpecujici provoz pri vypadku.
HeG umi pouzivat vice aplikacnich serveru, ovsem "zatez" se rozdeluje "od kusu" = rozdelule prihlasene uzivatele, nikoli realne vygenerovanou zatez. Ovsem jelikoz aplikacni srv jako takovy nedela prakticky nic, tak je to stejne jedno.
V pripade vypadku primarniho serveru, se HeG stane nepouzitelnym - uzivatele pripojeni na sekundarni zustanou (az do restartu IIS) pripojeni, novy uzivatel se neprihlasi. V pripade vypadku sekundarniho serveru to nejspis bude kazdemu "druhemu" uzivateli hlasit chyby pri prihlasovani (nebo to opet nepujde vubec - tuhle variantu sem netestoval). Klient se totiz natvrdo pripojuje na primarni server (o existenci sekundarniho nema ani poneti).

---
Ad triggery - oficialni reseni na doporuceni LCS, min 80% jich je primo od nich (jen tak lehce sem browsal po databazi z zjistoval co ze mi to tam tak hnusne brzdi moje jednoduchy query). Duvodem je, ze to jinak udelat nelze (pry).

---
A co se tyce navodu, jsou neuplne, informace v nich stoji za starou backoru, protoze system se chova vzdy jinak, nez je tam napsano, coz potvrdi spousta jinych lidi. Dodavatele externich aplikaci (napriklad) se musi sami metodou pokus omyl ucit se systemem komunikovat (a to vcetne tech, kteri jsou oficielnimi parnety LCS), protoze co je tam napsano jednoduse neni to, co system dela. Mimochodem, prechod na 43 z ust LCS "to neni migrace, to je vazne jen patch jako kazdej jinej" ... uz sem par informaci pobral od jinych zakazniku ... (a jejich adminu).

Patche jsou vubec kapitola sama o sobe, kdyz se me takova blbost jako trebas MeGUI umi zeptat, jake komponenty chci a jake nechci aktualizovat. V pripade LCS se me nic nezepta a tak si kvuli ucetnicvi rozbiju sklad/komunikaci s externima aplikacema/... (opakovana zkusenost) ... protoze nekdo vymyslel nejakou dalsi uzasnou featuru, pripadne opravil nejakou "chybu".

BTW: Prijde vam normalni ze se doklad chova ruzne podle toho z jake strany do nej vlezete? Asi jo, kdyz to pisete. Zrovna cerstva zkusenost.

[Marty]

Ad MS SQL. Dovolil bych si pár maličkostí:
- failover cluster na MS SQL je teoreticky pro aplikaci zcela transparentní, protože se schovává za virtuální IP/jméno a služba clusteru si to už na nižší úrovni někam směřuje; aplikaci je buřt, co se s jeho dotazy děje, důležitý je, jestli na korektně položenej dotaz dostane korektní data.

- rozložení dat jedné tabulky do více souborů aneb partitioning - smysl to má dle mého názoru spíš pro odlití archivních dat pryč, aby pracovní datové soubory nebyly příliš velké. Partitioning kvůli paralelizaci budiž, ale to by musel být sakra HW... no ten ostatně máte Takže klidně, ale viz dále - pravidla pro filegroupu a počet jader:

- spíš než partitioning bych uvažoval o větším množství souborů ve filegroupách a konkrétní tabulky (např. subjekty) bych nasměřoval do jedné filegroupy s odpovídajícím počtem souborů (počet jader>n & počet aktivních disků v poli>n), takže např. na 4jádrovým stroji s RAID5 bych udělal filegroupu FG_SUBJEKTY s třemi soubory; recreatnul subjekty CREATE lcs.subjekty ON FG_SUBJEKTY [...]

- v triggerech pokud možno nevolat ad-hoc dotazy, i když parametrizované, ale uložené procedury (cachují se pro ně execution plany a je to rychlejší, nežere to paměť)


Na hraní je toho dost...
Pošlu ti zejtra jeden dotázek, docela by mě zajímala statistika waitů nad vaší DB

[Jezevec]

Toreticky to transparentni je, ale nikoli pro LCS , neboj se, presne na tohle sem se jich (mimo jiny) ptal. Na ruzny metody optimalizace jakbysmet, a jelikoz nejsou schopni rict ze to s tim nastavenim bude fungovat, tak to zkouset nebudu.

[Jezevec]

Pro zajimavost, jak vypada chybova hlaska pro uzivatele:

PrivetivaChybovaHlaska.jpg

[D_a_v_i_d]

Tak to je kvalitní Čekal bych aspoň něco jako "odeslat správci systému" nebo něco takovýho

Tipnu si na průběh hovoru s uživatelem, kterému tohle vyskočí? (U: uživatel, A: admin)

U: Dobrý den, pracoval jsem s Heliosem a vyskočila nějaká chybová hláška
A: Jaká?
U: Taková velká, bylo tam napsáno, že se mám obrátit na správce
A: OK, co ještě se tam psalo?
U: Já nevím, ale bylo to přes půl obrazovky, nerzouměl jsem tomu a bylo tam jen tlačítko OK, tak jsem ho stiskl a ono to zmizelo...

[Jezevec]

Jop, takhle nejak to funguje, v tomhle pripade sem nastesti samo vedel co se deje, protoze sme lehce ladili srv a on holt neustoji restart printserveru, tak sem ho musel restartnout a tohle to hlasi kdyz aplikacni srv nebezi (clovek by ocekaval jednoradkovou hlasku ze se nelze pripojit k aplikacnimu serveru XYZ). Ale ve spouste jinych situaci uzivatel jednoduse neni schopen ani popsat, jak se k ty chybe dopracoval a i kdyz je a povede se stav navodit, tak stim jakozto admin muzu delat leda kulovy, protoze opravdu nevim co to dela na radku 105 ...

[dante]

No abych se taky pripojil troskou do mlyna na tema hg.

Neznam cloveka ktery by byl s hg spokojen. Delam ve firme ktera mela cca 700 useru. Mel jsem tu cest pozorovat prerod z norisu na hg. Dnes si o tom myslim ze si znas tehda lcs delalo snad srandu. Pamatuju na jajich studie nasazenia dalsi tlachy ktere s slusne zplatily spolu s partnerskou firmou. Vysledek nakoupeny hw za x mio na kterem se farma stourala v nose. A client pc se ohulil tak ze skoro roztekl takze se pak zase investovalo x penez do upgrade stanic. A to jen proto ze se to temer vse narvalo na tlusteho klienta. Viva microsoft gold partner...

Dalsi usmevne tema byl prevod z pb na .net platformu. Super... vysledkem je ze dodnes slozitejsi sablony vyrabej v pb11. Takovehle nalozeni s dw jsem opravdu necekal. Clovek nevedel jestli se tomu ma smat nebo brecet. A to bylo i obdobi kdy jsem skonci s betatestovanim pro lcs. Protoze vyvijet nastroje jen aby ten jejich zazrak fungoval kdyz oni toho nejsou schopni a za dara me fakt nebavilo.

Dalsi kapitolou jsou patche a prava.. A to pomijim obodbi kdy se predelaval system prav. Po kazdem patchi se pravidelne rozesere konzistence prav. Nekteri uz nemaji co meli a jini ejhle na co tady mam to tlacitko. Na chybky jsem asseco i jejich vyznamneho partnera upozornoval nicmene uz me nebavi hledat kde to zas podelali. Dale jak mi bylo zdeleno od dodavatele oni to proste na farmach neskousej. Takze se bezne stavalo ze se to uz nerozjelo a nebo rozjelo ale s takovymi problemy ze bych se utelefonoval s usery. Takze se prohazovaly farmy mezi sebou radej. O rozdelni zateze a dalsich super vecich jako redirectovani a terminalove servery ani nehovorim.

SQL njn lidi kupte si poradne zelezo za par mio a budou dotazy trvat jen par minut Co rict vic na jejich tabulku lcs.subjekty ktera treba unas ma 19 716 280 zaznamu... takze si jedinci kteri o hg neco vedi dovedou predstavit jaky hw asi taha tu paseku ve vnitr hg.

Jako byvaly prog rikam ze se mi jezili obcas hruzou vlasy na hlave kdyz jsem do toho systemu stouchal klackem. Ale tady uz jsme u toho co od toho muzem chtit kdyz radej investuji do marketingu a nadstandartnich vztahu nez do kvality vyvojaru ci vyvoje.

Ale abych jen nenadaval kdysi jsem z povzdali videl neco cemu rikali tusim pis bezelo to na vodarnach v ostrave snad i na sme. A myslim ze az na to ze to bylo postavena na pb (ano dw je krasna vec) to nebyl uplne spatny system na ten pravek.

[Jezevec]

Vitej do klubu

BTW: Vymysleli novou uzasnou featuru - oddeleny patchovani mezd. Vsemozny maily co kde je treba prekonfigurovat mi chodej takovym tempem, ze to vidim na dalsi akci migrace => 1/2 toho prestane fungovat a ta druha bude delat uplne neco jinyho nez se ceka.

BTW: V subjektech mam cca 1/2 - kolem 10M .

[dante]

Tak mam v prackach relativne novou instalacku HG. Neb jsem nucen neco otestovat. Mimochodem domain opravneni pro version manager ji tak nejak nefunguje. Na w2003s to napise ze sw byl uspesne nainstalovan bez hlaseni nebo tak nejak a pak plachata o tom ze ap server je nedostupny typuju na prava na sdilenich. Kdysi ta instalacka aspon zarvala ze nemuze zapsat protoze... tet je jeste lepsi... docela me udivuje ze za ty roky nebyli schopni doladit instalacku serveru.

[Jezevec]

Nj, dyk ty kkti dodnes neumej nainstalovat na 64bit widle - musi se rucne editovat ODBC profil v registru (tuhle kktinu potrebujou kvuli tisku, kerej je kapitola sama o sobe).

Klient je to samy - neumej to nainstalovat tak, aby se to dalo aktualizovat bez drbani prav pod userrem.

Nejvic me dojala konfigurace "clusteru" aby se dal aktualizovat z jednoho stroje - vivat bezpecnost (je treba do site nasdilet prakticky vsechno), takze sem se na to vybod a patchuju kazdej zvlast (ono to ma i dalsi vyhody - kdyz se neco podela, tak mam jeste druhej funkcni a staci mi zmenit DNS a preflaknout konfigurak). Nebo jejich pindy ze se to da aktualizovat za chodu ... a kdyz sem se zeptal, jak za chodu zmenej strukturu DB tak cumeli jak ...

Default "bezpecna" konfigurace serveru (dle jejich wiki) je taky uzasna - RW prava pro vsechny do adresaru aplikacniho serveru ... sem to cely musel prekopat a samo predelat na https.

[Marty]

Hele, Michale, teď si tak vrtám v testovací DB a koukám, že subjekty nejsou definovaný jako clusterovanej index. Jen tak z legrace jsem si ho tam nadefinoval nad cislo_subjektu a select do lcs.subjekty se zkrátil na dvě třetiny původního času.

Nechceš to testnout nad nějakým větším počtem záznamů a na nějaký větší dotazy? Já mám testovací jen s 30 tisíci subjekty...

edit
před:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'subjekty'. Scan count 0, logical reads 3, physical reads 3, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 2 ms.

po:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'subjekty'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 15 ms,  elapsed time = 2 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 1 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

edit2
ty fyzický čtení v druhým případě jsou tím, že to bylo už v RAM.

[Jezevec]

Se podivej do nasi DB ... tohle tam samo uz davno mam, LCS jsou totalni trotlove - bez toho byly nektery operace i 50x pomalejsi. Dyk pri testovaci migraci sem zrusil vsechny svoje indexy a nedalo se to pouzivat - to tak ze vubec, trebas jen pridani radku na poptavku trvalo minutu.

Problem je, ze oni query generujou nejakym shitoznim generatorem, a naprosto s klidem joinujou tabulky pres textovy pole. Nektery sablony sem predelaval rucne a byly 10x+ rychlejsi (i pri tom bidnym navrhu db).

Sem pridaval celkem hromadu indexu, coz samo zvedlo velikost DB (zhruba na dvojnasobek) a ponekud (ale jeste akceptovatelne) zpomalilo inserty. Tusim ze nejaka ucetni operace se potom z nekolika hodin zkratila na radove minutu ...

Jak sem uz psal, tomu nerikam optimalizace, ale totalne zmrvena databaze. Optimalizaci se da v optimalnim pripade ziskat 10%.

Edit: Ja sem dokonce takovej dobytek, ze si dovolim v subjektech mazat , oni totiz ti kreteni generuji log XML prenosu jako subjektovej a za tejden vygenerujem asi mililon zaznamu. Smazat tech milion zaznamu z HeG je tak na 14 dnu ... , v DB to smaznu za vterinu.

[Marty]

Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.

[Jezevec]

Pro zajimavost, podle tech kretenu je to, ze zaznam v logu neobsahuje ZADNOU vazbu na doklad ke kterymu patri normalni ....

[caruso]

Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.

Ano, z vlastní zkušenosti souhlasím, je to obecný problém architektury tříd v Helios Green. Helios Green používá "posun do META", kdy všechny hlavičkové záznamy v jsou subjekty, tím získává datový návrh značně na flexibilitě, ale klesá také silně výkonnost databázového stroje. Pokud tabulky jako subjekty nebo sk_polozka narostou do desetimilionovych řádů, pak dochází k vzájemné blokaci uživatelů při určitých operacích, pracujícíh s větší množinou záznamů. Je vcelku jedno, jestli uživatelů je 100 nebo 5, blokuje se tabulka subjekty a treba take sk_polozka a vyrobce na to ma specialni udelatko, kterym blokovani presahujic rozumny cas odstreluje, jinak je treba restart SQL Serveru.
Řëšením by měla být dle mého názoru archivace záznamů do archivní databáze. Pro opravdu veliké projekty, kde vznikají miliony záznamů skladových pohybů relativně rychle, se myslím Helios Green nehodí, pro střední firmu ale je OK.