Bestaande basis importtijd, archieftijd / initiële archiveringsmethode

Hallo

 

Ik ben bezig  met het archiveren van mijn 80 GB aan bestaande solidworks-bestanden.

Ik werk direct op afstand op de archiefserver (gevirtualiseerde server nogal high-end).

Hier is een schatting van de keren die ik krijg:

- kopie van SW-bestanden van het netwerk naar de lokale weergave van de kluis: ongeveer 10 uur voor 80 GB of een 2 MB/s (dit is niet te vergelijken met de kopieertijd van netwerk naar schijf omdat EPDM meer bewerkingen uitvoert dan de eenvoudige kopie: het maken van een bestand in de kluis naast die in de lokale weergave, het aanmaken van vermeldingen in de SQL-database ..)

- eerste archivering van bestanden: ongeveer 40 gearchiveerde onderdelenbestanden per minuut (er is een workflow om de index van het bestand automatisch in EPDM in te vullen zodat sommige bestanden aan het einde van de archivering bij versie 5 terechtkomen)

Vindt u deze kopieertijden en archieftijden normaal?

 

De eerste archivering is ook erg vervelend, SW en resellers raden aan om eerst de SLDPRT's te importeren, dan de SLDASM's en dan de SLDDRW's. Hiervoor heb ik ofwel een dispatch gebruikt (zie mijn vraag over het onderwerp), maar het stopt bij elke fout/waarschuwing (bestand niet gevonden, duplicaat ....) dus het is niet praktisch. Ik heb ook geprobeerd de zoekfunctie te gebruiken om een bepaald type bestanden te filteren en te archiveren, maar met een database die te groot is, is het niet mogelijk om dit op de hele database te doen en dit directory voor directory doen (ik heb 1000 plannen per directory) is erg lang en pijnlijk. Als ik gedwongen word om de laatste methode te gebruiken, zal de archivering die nodig is voordat ik EPDM kan gebruiken enkele dagen duren, waarin ik mijn collega's op technische werkloosheid zal zetten...

Is er een eenvoudige en snelle methode om deze eerste archivering te doen (als ik tegelijkertijd ook de lijst met fouten/waarschuwingen in een bestand kan krijgen, zou het de droom zijn).

Bedankt voor je feedback

 

Tijdens onze tijd bij EPDM hadden wij (@Benoit.LF en ik) net als jij veel gegevens te verwerken .

We hebben vooraf heel wat "opschoning" van de gegevens gehad via de INTEGRATION-tool om eventuele fouten tijdens de EPDM-archivering te voorkomen.

We hebben eerst de SLDPRT+SLDDRW geïmporteerd en daarna de SLDASM.

De invoer in de EPDM gebeurde 's avonds en 's nachts en in het weekend (in verpakkingen van 1000 referenties), eenmaal geïmporteerd in de EPDM werden deze niet-EPDM-referenties geblokkeerd in de read-only-modus (het was dus onmogelijk voor onze collega's om de minste wijziging aan deze onderdelen aan te brengen).

Vanuit huis via TeamViewer namen we de controle over alle of bijna alle werkplekken van onze collega's over om zoveel mogelijk tijd te besparen.

Eenmaal geïmporteerd en gearchiveerd, via een import WF (om met name de indexeigenschap te matchen met de EPDM-index) wachtten de onderdelen en tekeningen op validatie, en na verloop van tijd gingen de bestanden na een snelle visuele controle naar de status GELDIG.

Qua tijd weet ik het niet meer, maar uit mijn hoofd was het vrij lang.

1 like

@Flegendre

Bedankt voor je feedback.

Ik vroeg me af hoe ik kon voorkomen dat de BE werd geblokkeerd tijdens de EPDM-omschakeling. Uw oplossing om de in EPDM geïmporteerde bestanden alleen-lezen te maken op de oude server, stelt u in staat om op dit probleem te reageren, hoewel het een sterk verslechterde werking van de BE impliceert zolang de volledige failover niet is uitgevoerd.

Momenteel werk ik rechtstreeks op de archiefserver. Volgens uw bericht lijkt het erop dat u via verschillende lokale stations bent gegaan om de eerste archivering van de bestanden uit te voeren. Denk je dat je methode sneller was dan alleen op de server werken? Misschien is het feit dat je met 2 mensen parallel werkt (1 tot 2 minuten wachten op de rechtermuisknop om te reageren op een selectie van 500 tot 1000 bestanden een lange tijd)?

Inderdaad, we gingen via de werkstations en niet rechtstreeks via de server.

Theoretisch zou je direct vanaf de server sneller moeten zijn. We hadden de test tussen de 2 methoden niet gedaan, dus op dit punt kan ik je geen antwoord geven.

Idealiter is het om alles in een of twee weekenden uit te geven om zo min mogelijk problemen te krijgen...

Terug naar de importtijd van de database:

Op een database van 42 GB aan gegevens (46096 bestanden, 4503 mappen), kostte het me 2 en een halve dag om de bestanden te importeren (kopiëren/plakken in de kluis: ongeveer 3 tot 4 uur), vervolgens de eerste check in te doen in de map die gewijd is aan de import (ongeveer 2 dagen met inchecken  van de sldprt, dan de sldasm en vervolgens de slddrw, Dan alle andere bestanden die rondslingeren in de mappen (Office, PDF, IGS ...)).

Om in te checken maak je gebruik van de EPDM zoekfunctie en niet van de zoekfunctie in de verkenner (veel langzamer en crasht meer). Mijn tijden zijn vrij lang omdat ik bijna al mijn eigenschappen met betrekking tot de configuraties importeer en omdat ik een nogal gecompliceerde initiële workflow heb (het haalt automatisch de revisie van de bestanden op volgens de waarde van de eigenschap " revisie ")

Met de zoekfunctie kunt u batch-check-ins uitvoeren van 2000 tot 5000 bestanden (de kans is groot dat de check-in van tijd tot tijd wordt ingevoerd en aangezien de referentiezoektijd vrij lang is, is het beter om niet te veel bestanden tegelijk te nemen). Er is de mogelijkheid om meerdere zoekopdrachten en meerdere check-ins parallel uit te voeren op dezelfde machine. Aan de andere kant moeten de zoekopdrachten onafhankelijk zijn om te voorkomen dat een batch check-ins crasht omdat EPDM probeert een check-in uit te voeren op een bestand dat al in de kluis ligt: op onderdelen en MEP-bestanden werkt het goed door zoekopdrachten uit te voeren zoals 'S*.sldprt', Op assemblages is het riskanter omdat een subassemblage een naam kan hebben die niets te maken heeft met de initiële assemblage

Voer alle import- en incheckbewerkingen rechtstreeks uit op de archiefserver.

Omdat ik in een gevirtualiseerde omgeving zat, heb ik de EPDM-servers tijdelijk een boost gegeven: overschakelen naar 4 dedicated cores voor de SQL-server (niet per se erg nuttig op het einde omdat ik een CPU-bezettingsgraad van ongeveer 20% had, 2 cores zou zeker genoeg zijn geweest).

Zodra de import en de eerste check-in is voltooid in de speciale directory, moet u de mappen weer op hun plaats zetten. Dit mag ALLEEN worden gedaan op een machine met een lege lokale cache. Als je dit doet op de server met alle bestanden in de lokale weergave, is het vreselijk lang (je moet GB aan gegevens verplaatsen en EPDM kan de gegevens tijdens de overdracht bijwerken zodat de links in orde zijn bij het openen van de bestanden). Als de lokale weergave leeg is, gebeurt er niets op het werkstation en werkt alleen de SQL-server om de bestandslocatie-informatie te wijzigen (slechts één transactie per bestand wordt verplaatst).

 NB: mijn Amerikaanse reseller Trimech (die Moderntools heeft gekocht) heeft nu een tool om SW directories te analyseren voordat ze importeren. Deze tool scant SW-mappen en voert een database uit met alle links tussen bestanden, de eigenschappen in de bestanden.... (het was nog steeds enkele honderden MB's). Van daaruit is het mogelijk om via een aantal andere tools alle SW-bestanden te corrigeren die ongeldige referenties bevatten, onjuist ingevulde eigenschappen (ingevoerd op het bestand in plaats van op de configuraties bijvoorbeeld...) Ik heb deze tools niet in werking kunnen zien, dus ik weet niet hoe gemakkelijk ze te gebruiken zijn en hoe ergonomisch ze zijn. Mijn dealer wilde me niets laten zien als we niet deze kant op gingen, aangezien alles al gedaan was voor de 'traditionele' import wilde ik dit avontuur niet aangaan. Aan de andere kant kan dit soort tool nuttig zijn voor een bedrijf dat absoluut wil dat 100% van de gegevens die in EPDM worden ingevoerd, aan de eisen voldoen (dit is niet het geval aangezien we heel weinig hergebruik hebben : we hebben dus EPDM-gegevens ingevoerd die verre van schoon zijn, maar die we alleen zullen opschonen volgens een echte behoefte).

Ik weet niet of Axemble vergelijkbare tools heeft.

 

Ik hoop dat dit onderwerp nuttig zal zijn voor toekomstige dappere EPDM-beheerders wanneer ze voor het eerst importeren.