Wypowiedzi
-
Latency jest istotne, chodzi oczywiście głównie o Cache Fusion.
Oracle zaleca rozważenie użycia Infiniband ... :)
"Consider using Infiniband on the interconnect for workloads that have high volume requirements. Infiniband can also improve performance by lowering latency, particularly with Oracle 11g, with the RDS protocol"
Zaleca również uzycie dedykowanego switcha sprzetowego dla potrzeb interconnecta :
RAC: Frequently Asked Questions [ID 220970.1]
"Oracle RAC and Oracle Clusterware deployment best practices recommend that the interconnect be deployed on a stand-alone, physically seperate, dedicated switch.
Many customers, however, have consolidated these stand-alone switches into larger managed switches. A consequence of this consolidation is a merging of IP networks on a single shared switch, segmented by VLANs. There are caveats associated with such deployments.
The Oracle RAC cache fusion protocol exercises the IP network more rigorously than non-RAC Oracle databases. The latency and bandwidth requirements as well as availability requirements of the Oracle RAC / Oracle Clusterware interconnect IP network are more in-line with high performance computing"Przemysław Kamper edytował(a) ten post dnia 17.12.10 o godzinie 19:29 -
Aaa, v$dataguard_stats, myslałem, ze połknąłeś litere hehe i miało być v$dataguard_status. No tak, taki widok tez jest i wszystko sie zgadza.
Nie przejmowałbym sie takimi opóźnieniami w aplikowaniu logów. Mnie zawsze interesuje to czy nie ma problemów z transportem logów. W razie awarii taka zwłoka spowodowana aplikowaniem logów chyba nie spowoduje końca świata ;)
Monitorowanie. Sposobów jest wiele, może brokerek ? :) -
Zapewne chodzi o "log", a nie "lag" ;)
Napisz co chcesz konkretnie monitorować. 'switchover_status' służy do określenia możliwości przeprowadzenia operacji switchover, nie sądzę, żeby Cie to interesowało.
Do monitorowania aplikowania logow i ich transportu możesz używać widoku V$ARCHIVED_LOG (nie używaj V$ARCHIVE_DEST_STATUS - znany Bug 8822832 - V$ARCHIVE_DEST_STATUS has incorrect value for APPLIED_SEQ# [ID 8822832.8])
Ja używam skryptów OS albo narzędzi firm trzecich (np BMC Patrol). -
No ja widziałem ponad 90GB SGA ... :)
-
Swój biznes - wiadomo, najlepszy.
I niekoniecznie w IT, może nawet lepiej ;)
Nie chodzi mi oczywiście o samozatrudnienie. -
Podejście do sprawy Adama jest bardzo zblizone do mojego :)
Olimpia - wszystko zależy od firmy a przede wszystkim od działu i przełożonego. Słowo "korporacja" nie jest słowem-kluczem, które definiuje naszą pracę w danej firmie.
Ja pracowałem w kilku korporacjach i w kazdej było inaczej. Praca 'od-do', którą aktualnie masz, ale tez oczekiwanie dostępności 24x7 w innej.
Ja zdecydowanie lepiej sie czułem w mniejszych firmach. -
Ja mam doświadczenie z 3T, Poznania i Wawy.
W Wawie widełki to jak ktos napisał, 8k-12k brutto.
Zasadnicza różnica między stolica a prowincją ;) polega na tym, że jeśli ktoś chce pracować jako freelancer, to pozostaje mu w zasadzie tylko Warszawa. Więcej tu centrali firm międzynarodowych, które sa bardziej otwarte na taki rodzaj współpracy.
A co lepsze - kontrakt czy etat ? Hmmm. To jak dyskusja o wyższości świąt Bożego Narodzenia nad Wielkanocą. Wszystko ma plusy i minusy. Dużo zależy od charakteru, sytuacji rodzinnej etc.
Indywidualiści zapewne wolą kontrakty czasowe. Nie trzeba udawać, że kocha sie firmę i wykrzykiwać rano "Jesteśmy najlepsi" :) -
To sprawa sie wyjaśniła. Jak na razie środowisko działa bez zarzutu po moim eksperymencie:)
Przy okazji, jeśli sie przekonwertuje tablespace z użyciem CONVERT TABLESPACE nie oznacza braku problemów. Robiłem to ostatnio przy migracji z AIX do Oracle Linux i wykładał sie przy otwieraniu bazy. Okazało się, że problemem są segmenty temp w tablespace.
Co do supportu - środowisko jest testowe więc support jest zbędny (zresztą był kilka tyle lat zbędny ;)). -
Tak jak obiecałem - sprawdziłem i daję znać.
I cóż - poszło :) -
Będę to niedługo sprawdzał, to dam znac co i jak ;)
-
Panie i Panowie, bo juz zgłupiałem.
Jest case jak w temacie, systemy Linux Oracle i Windows 2003 S. Sprawa jest oczywista - OS maja ten sam endian, a więc RMAN Convert Database powinien załatwić sprawe.
Natomiast klient twierdzi, że poprzedni konsultant eksperymentował i stwierdził, że można to załatwic poprzez proste kopiowanie datafile'i ... :(
Przeryłem metalink, asktom itd itp i ZERO. Logika równiez wskazuje na to, że to nie może sie udać, ale może Wy spotkaliście sie z jakims cudownym rozwiązaniem.
Pozdrawiam
PK
PS. Pomijam oczywiście rozwiązania typu imp/exp.