Wróć do czasu importu bazy danych:
Na bazie danych o pojemności 42 GB danych (46096 plików, 4503 folderów) zaimportowanie plików zajęło mi 2 i pół dnia (kopiowanie/wklejanie w magazynie: około 3 do 4 godzin), a następnie wykonanie pierwszego zaewidencjonowania w katalogu przeznaczonym do importu (około 2 dni z zaewidencjonowaniem sldprt, następnie sldasm, a następnie slddrw, Następnie wszystkie inne pliki leżące w katalogach (Office, PDF, IGS ...)).
Aby dokonać odprawy, skorzystaj z wyszukiwarki EPDM, a nie z wyszukiwania w eksploratorze (znacznie wolniej i bardziej się zawiesza). Moje czasy są dość długie, ponieważ importuję prawie wszystkie moje właściwości związane z konfiguracjami i ponieważ mam dość skomplikowany początkowy przepływ pracy (automatycznie pobiera wersję plików zgodnie z wartością właściwości " revision ")
Za pomocą narzędzia wyszukiwania wykonuj zbiorcze ewidencjonowanie od 2000 do 5000 plików (istnieje prawdopodobieństwo, że zameldowanie się następuje od czasu do czasu, a ponieważ czas wyszukiwania referencyjnego jest dość długi, lepiej nie brać zbyt wielu plików na raz). Istnieje możliwość przeprowadzenia kilku wyszukiwań i kilku odpraw równolegle na tej samej maszynie. Z drugiej strony, wyszukiwania muszą być niezależne, aby uniknąć zawieszenia partii zaewidencjonowań, ponieważ EPDM próbuje dokonać zaewidencjonowania pliku, który jest już w sejfie: na częściach i plikach MEP działa dobrze, wykonując wyszukiwania takie jak "S*.sldprt", W przypadku zespołów jest to bardziej ryzykowne, ponieważ podzespół może mieć nazwę, która nie ma nic wspólnego z początkowym złożeniem
Wszystkie operacje importowania i ewidencjonowania należy wykonywać bezpośrednio na serwerze archiwum.
Będąc w środowisku zwirtualizowanym, tymczasowo wzmocniłem serwery EPDM: przełączając się na 4 dedykowane rdzenie dla serwera SQL (niekoniecznie bardzo przydatne w końcu, ponieważ miałem wskaźnik wykorzystania procesora na poziomie około 20%, 2 rdzenie z pewnością by wystarczyły).
Po zakończeniu importu i początkowego zaewidencjonowania w dedykowanym katalogu należy umieścić katalogi z powrotem na swoim miejscu. Należy to zrobić TYLKO na komputerze z pustą lokalną pamięcią podręczną. Jeśli zrobisz to na serwerze zawierającym wszystkie pliki w swoim widoku lokalnym, to jest on strasznie długi (musisz przenieść GB danych, a EPDM może zaktualizować dane podczas przesyłania, aby linki były OK podczas otwierania plików). Jeśli widok lokalny jest pusty, na stacji roboczej nic się nie dzieje i tylko serwer SQL pracuje nad zmianą informacji o lokalizacji pliku (przenoszona jest tylko jedna transakcja na plik).
Uwaga: mój amerykański sprzedawca Trimech (który kupił Moderntools) ma teraz narzędzie do analizy katalogów oprogramowania przed importem. To narzędzie skanuje katalogi oprogramowania i generuje bazę danych zawierającą wszystkie powiązania między plikami, właściwości zawarte w plikach.... (nadal było to kilkaset MB). Z tego miejsca można poprawić wszystkie pliki oprogramowania zawierające nieprawidłowe referencje, nieprawidłowo wypełnione właściwości (wprowadzone w pliku zamiast w konfiguracjach na przykład...) za pomocą wielu innych narzędzi. Nie byłem w stanie zobaczyć tych narzędzi w działaniu, więc nie wiem, jak łatwe są w użyciu i jak bardzo są ergonomiczne. Mój dealer nie chciał mi nic pokazać, jeśli nie pójdziemy w tym kierunku, ponieważ wszystko było już zrobione dla "tradycyjnego" importu, nie chciałem rozpoczynać tej przygody. Z drugiej strony tego rodzaju narzędzie może być przydatne dla firmy, która absolutnie chce, aby 100% danych wprowadzanych do EPDM było zgodnych (tak nie jest w naszym przypadku, ponieważ mamy bardzo mało ponownego wykorzystania : wprowadziliśmy zatem dane EPDM, które są dalekie od czystości, ale które wyczyścimy tylko zgodnie z rzeczywistą potrzebą).
Nie wiem, czy Axemble ma podobne narzędzia.
Mam nadzieję, że ten temat przyda się przyszłym odważnym administratorom EPDM przy pierwszym imporcie.