eleg sok leiras van, meg megoldas, neked egyik sem segitett vagy meg utana sem neztel? keres es peldaul a http://www.orafaq.com/forum/t/65588/0/ ? Nem sokat irsz sem a kornyezetedrol sem semmirol. Az meg hogy "nem megy" valami valahol, nem valami informativ.
>>>>>>>>>>> Elvagyok a gyenge képességű programokkal, és megpróbálok a magam módján hozzátenni annyit, hogy jobban működjön a végeredmény. Szóval felesleges szidni az OWB-t, jól el lehet azzal is buherászni. Majd jön hozzá peccs. :) >>>>>>>>>>>y
A cikk mérnökének egyik mondatával reflektálnék => ' Végül is igazad van. De ez a te igazad, nem az enyém.'
;)
Kétségtelenül reális álláspont, mindannyian próbálunk így-úgy megfelelni neki. Senki nem akarja a világot megváltani...Azt azonban a magam részéről gondolom, ha valami romlás; azt azért legalább minimálisan vegyük már észre (még ha elgondolkodni rajta nem is érünk rá), és ne állítsuk be természetesnek.
Egyébként gazdasági alapozású érveléssel is levezethető talán, hogy az idézet gondolatmenet lehet káros is.
Nem mindegy, hogy valaki beruház egy windows registry optimalizálóba, és kockáztat minden egyes futtatásával, vagy eleve nem hagyja teleszemetelni és sose lesz neki szüksége 'vérfrissítő reinstallra'. El lehet gondolkodni melyik eljárás szimpatikusabb és olcsóbb a buherálást illetően (így kicsiben)
A "buherászásnak" és "peccseknek" is van ám nemkicsi infrastrukturális meg humán költsége (belső tesztelés, időtényező, tévedési lehetőség miegymás), ami ráadásul mindenkinél jelentkezik kivéve a sz*rt szállító fejlesztőnél nem, ugye... ;) Az ilyen lavírozás is izgalmas szellemi kihívás (lehet, legalábbis egy ideig), de nem lenne inkább kifizetődöbb értelmes problémákon dolgozni helyette?
PS: Egyébként már többen írtátok ezt a 100%-os termék-csinálás problémát. - Én egyrészt megértőbb vagyok, mert azt gondolom, létezik mai is olyan feladat (pl.: neurális hálós, fuzzy rendszeres adatbányászati technológiák), ahol a jelenlegi tudásunkkal majdhogynem lehetetlen tényleg jót csinálni. (Spéci versenyek témája, hogy egyáltalán mit és mennyire lehet általánosítani, nem hogy azt még implementálni is egy kereskedelmi vagy vagy free szoftverben...) - Másrészt nem győzöm hangsúlyozni; szerintem vannak fokozatok, van különbség bug és bug között illetve bugosság és bugosság között. - Harmadrészt nem mindegy, hogy valami eleve koncepcionálisan sz*r, vagy pusztn csak egy nem megfelelő release került ki a gyártó kezéből, amit másnap azonnal orvosolni lehet (bocs mindenkitől, de szerintem a Windows Vista _koncepcionálisan_ problémahalmaz, de mondhatnám a Borland Delphi 200* Studiót is, de ez innentől már tényleg off /különben is saját szubjektív vélemény/) - Negyedrészt szerintem igen is vannak szoftverek, nem is kevés, ami emberi léptéküek (amit vállalnak azt tudják) és minőségük aszimptotikusan konvergál a 100%-hoz.
Elnézést az offért, csak szeretném megvilágítani kicsit a másik oldalt is. Lehetne csinálni 100%-osan működő termékeket, de mégsem csinálnak és ennek ugye a pénz az oka. Minden cég, aki szoftverfejlesztésre adja a fejét, épp csak annyit tesz bele a szoftverébe, hogy a megefelelő piaci részesedést ki tudja hasítani. Néha még annyit sem, de olyankor segít a marketing. A másik oldalon pedig, amikor egy cég megvesz egy terméket, el sem várja hogy az 100%-osan működjön. Miért is kellene? Ez nem űrhajó, vagy atomtengeralattjáró. Ezen lehet keseregni, de szerintem felesleges. Legalábbis én letettem róla egy ideje. Elvagyok a gyenge képességű programokkal, és megpróbálok a magam módján hozzátenni annyit, hogy jobban működjön a végeredmény. Szóval felesleges szidni az OWB-t, jól el lehet azzal is buherászni. Majd jön hozzá peccs. :)
>...az összes üzletileg sikeres sziftvercégre is kiterjeszthető. A mamutokra legalábbis biztosabban. De az arányok azért kisebb-nagyobb mértékben eltérhetnek cégek vonatkozásában is, termékek vonatkozásában is. Az OWB mondjuk kiugróan negatív példa (legalábbis számomra)
Jó ötlet mindig is volt/van/lesz, IT vonalon. De a pénzügyi, marketing, kapcsolati meg a szakmai tőkék közül a legutóbbi valahogy egyre inkább egyre vészesebben szorul háttérbe , ahogy én érzékelem.
Nem véletlen, ahogy szinte azonnal felvásárlódik egy jó ötletből készült termék mögötti cég valami nagy hal által (a koncentrálódás jegyében). Illetve nem véletlen az a sok irányból erösődő tapasztalat sem, hogy a "nagy hal" mit képes néha művelni 'termékfejlesztés' címén (a tulajdonában lévő termékével).
Kozben megoldodott. Azt hiszem azert nem ment mert futott az AVG center de leallitottam es elindult. Gondolom a tuzfalak miatt nem indult, de most mar megy :)
Lenne egy kerdesem, nekem Oracle 10g-m van, es amikor a start menubol el akarom inditani a "GO TO DATABASE HOMPAGE" -t akko az explorer nem tudja megnyitani az oldalt, milyn beallitasokkal van gond?
Az írás viszont találó és - ezért sajnos, hogy - szomorú hangvételű. Az OWB-re való utalás - szintén sajnos - erősen általánosítható: igazából ma már gyakorlatilag az összes üzletileg sikeres sziftvercégre is kiterjeszthető. Próbáltam tárgyilagos és részletekbe menő összehasonlítást találni a különféle adatbázismotorok közt. Nekem nem sikerült :( Amiket találtam, jellemzően arról szóltak, hogy az adott termék mennyire jó és a többiek mennyire rosszak - minden szempont szerint, kivétel nélkül. Nem nagyon hihető...
Hmmm, az lehet. Én csak hozzáadni próbáltam. Nálunk az dívik csak szerencsére. Érdekes megjegyezni, hogy attól, hogy a táblán most az van beállítva, hogy NOCOMPRESS, attól még lehetnek benne korábbról tömörített blokkok, és akkor (helyesen) az add column ugyanúgy problémázott (9i-ben). Szóval ilyenkor kap egy szép "move nocompress"-t, hozzáadjuk az oszlopot, aztán "move compress". Partícionált táblánál minden partíciót néz (szintén helyes), úgyhogy 10g elött biztos nem fogjuk kipróbálni az 1.5 TB-os OLTP rendszerünkben a 30-100GB-os táblák régi partícióira - ennyi állásidőnk nincsen, főleg nem egy amúgy 1perces műveletre.
Mi hiba, mi nem.... A 9i2 doksinban az ADD COLUMN-nál nincs leírva, hogy compressed táblán nem lehet. 10g2-es doksiban meg "aszondják", hogy default értékkel nem lehet :) Tulajdonképp írhatták volna megoldásnak, hogy a doksi hibás. Esetleg ki is javíthatnák a doksit. És akár a compressről szóló szép szövegekben ("használjátok, mer' az jó"), meg is lehetne említeni a hátrányok közt.
Az a bug szerintem sajnos csak arra vonatkozik, hogy a hibaüzenet nem helyes, mert félrevezető szöveget mutat. Például "ORA-12996: cannot drop system-generated virtual column" jön a helyes "ORA-39726: unsupported add/drop column operation on compressed tables" üzenet helyett.
Még 10gR2-ben sem tudsz tömörített táblából oszlopot eldobni.
BTW, nem véletlen ajánlottam korábban OWB-mappingek tanulmányozását, forall és/vagy táblafüggvények-re bőven tudsz találni példát.... nyílván a neten is, de mivel az OWB ízig-vérig Oracle-termék ("nem egy benyelt kishal"), azt gondolom érdemes lehet böngészni mire jutott az évek során a témában... ;) Persze nem akarlak rábeszélni, félre ne érts!
>>"A repository-technológia (designer, discoverer, owb stb.), alapvetően elhibázott koncepció" >Pontosan mi a bajod a repository koncepcióval? Mi lenne a jó helyette?
Meglehet, hogy virtuális népharagot fog kiváltani a hozzászólásom... ;)
Mivel lesznek szubjektiv elemek is ezért kezdetnek pár tény:
1. Windows Vista & "adatbázisszerű" WinFS napjainkban is zajló pro-kontra története http://index.hu/tech/blog/2007/06/26/halal_a_windows_longhornra/ http://longhorn-reloaded.org/
2. Sourcecode Version System -> filerendszer kontra DB szervezésű tárolása Amikor foglalkoztam a kérdéssel behatóbban, egy-két szoftvert találtam, ami a DB-t (is) támogatta
3. Firefox & sqlite ami mostanság van napirenden
Mi a közös (szerintem) az Oracle Designer, OWB-t, stb is immár bevonva, repository technológia szemszögéből...
- Mikró környezet (nem sok felhasználó, nem egeket ostromló párhuzamos feldolgozás) - Speciálisabb feladatok ahhoz képest, amiben a relációs adatbázis nagyon jó eszköz - Továbbra is létezik tulajdonképpen 'ekvivalens' alternatíva (pl.: filerendszer) - Lehet összevetni egy (automatikus!) filerendszer-s migrálást a db-migrálással.... Sokkal-sokkal nehezebb az utóbbi, nemvéletlen, hogy annyit hibázott az Oracle - Minden DB-környezet drágább, sőt talán a legdrágább a teljes életciklust tekintve - Nehéz repo-tervezéskor relációs strukturát tervezni és azt időnyomás alatt állandóan módosítgatni - Tervezési-komplexitás egy határon túl nő, nemvéletlen az OO és XML típusú eltérés a 100% pure relációs adatmodelltől. A DW-k tervezési módszertanáról már ne is beszélve... ;) Kézenfekvő kedvenc példám: nem mindegy, hogy egy mező azért null mert megengedi a definició, vagy azért, mert hiba történt...
Zárszóként, én nagyon sok eszközt kipróbáltam, hogyan tudnám leghatékonyabban "átlátni" irdatlan levéladatbázisomat (de mondhatnám a favorites-okat is). Azonkívül, hogy maradéktalanul szimpatikusat egyet sem találtam (azaz meg kéne írni) a Total Commanderes file-rendszeres (környezetfüggő!) kezelésnél hatékonyabbat nem találtam. Ismerjük az "egymiliárd légy nem tévedhet" effektust ;), de nem véletlen, hogy ennyi akadály van a valós életben is. Nem vitás, hogy van előnye is az egész repo-témának (pl.: regexp-es relációs keresés, ahogy szó is volt róla), de ahogy mondtam költsége is van a dolognak...
Így már teljesen OK! :o) Abszolút valós szitu amit írsz, én is számtalan ilyenben voltam... Ami meg a TPC-H-t illeti, na ez az amiről beszéltem... ;)
A history-kezelésnél szerintem alapelv, hogy minél régebbi az adat benne, annál olcsóbb (igaz lassabb elérésű) háttértáron a helye. Ez bőven lehet a compress tárgya, majd az élet eldönti, hogy életképes új alternatíva-e.
sarki lény, KingFishR, az lehet, verziót nem említettél, s.l., csak RAC-ot, bár én sem kérdeztem rá. Nekünk RAC-ból csak 10g van, 9i RAC-cal nem is dolgoztam korábban sem, így nekem ez volt a természetes, és ahogy a doksijában te is olvasod, ott így is működik. Pontosabb hibameghatározást és körülményleírást ezentúl. ;-)
Az elvileg már a 10g-ben is ki van javítva, nemtom miért new feature. Azért az vicces, hogy elég régóta bugnumber (2421054) van hozzárendelve, hogy "nem megy az add column compressált táblán", és volt pof*juk azt írni, hogy "10g-ben javítva". Esetleg kaphatnánk 9i2-re egy szép kis patchet, nem??? Lehet, hogy az a new feature, hogy mostmár tényleg menni fog??? ;-)
9i RAC-ban a redo logoknál nem csak a group meg a member változik, hanem a thread is. Minden instance-nak saját redo thread-je van. Minden instance saját magának archivál, a többiekét nem bántja. Így minden instance-nak a redo és az archlog lokálisan keletkezik. Ezért is érdekes munka pl. egy szép nagy helyreállítás...