Jaki jest właściwy sposób tworzenia kopii zapasowej geobazy danych pliku ESRI, która jest publikowana na ArcGIS Server?

11

Mam geobazę pliku ESRI (v10), która jest opublikowana w usłudze map serwerów Arcgis. Gdy usługa jest uruchomiona, fGDB jest zablokowany. Czy muszę zatrzymać usługę, aby uzyskać czystą kopię zapasową? A może istnieje sposób wykonania kopii zapasowej za pomocą skryptu arcpy lub katalogu? Obecnie używam robocopy Windows do przeniesienia fGDB na dysk zapasowy. Oto wynik pokazujący zablokowane pliki:

 New File           0 Bikepaths.CFP0026.4968.5140.sr.lock
 New File           0 BuildingFootprints.CFP0026.4968.5140.sr.lock

itd itd...

mogollon22
źródło

Odpowiedzi:

4

Każdy serwer powinien mieć dysk w tle. Możesz użyć „dysku cienia”, aby skompaktować geobazę plików, co spowoduje usunięcie plików .lock i zmianę kolejności pliku w najbardziej efektywny sposób. Następnie możesz wykonać kopię zapasową tego pliku. Oto dobra para dobrych punktów wyjścia:

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/File_geodatabases_compressing_vs_compacting/003n0000007r000000/

Uwaga: Dysk Shadow ma inną nazwę dublowania dysku

http://en.wikipedia.org/wiki/Disk_mirroring

Mapperz
źródło
Ach, zawsze zakładałem, że kompaktowanie dotyczyło geodezyjnych baz danych. Dzięki!
mogollon22
Zarządzam kilkoma serwerami i żaden z nich nie ma napędów w tle lub dublowanych, chociaż mają one nadmiarowe dyski (RAID5, Drobo) i mogą przetrwać awarię jednego lub większej liczby dysków bez utraty danych. Niezależnie od tego sprzeciwu, kopiuję pliki fgdb za pomocą xcopy(lub xxcopy ), pomijając błędy, a następnie kompaktuję wynik. Nie jest to najlepsze rozwiązanie, ponieważ klasa obiektów zablokowana z powodu sesji edycji może zostać uszkodzona, ale nie różni się to od napędu w tle / w lusterku.
matt wilkie
2

Mamy kilka produktywnych aplikacji internetowych, które działają na FGDB na backendie. FGDB są usuwane i przebudowywane co noc ze świeżych danych. Mamy napisaną przeze mnie aplikację konsolową .NET opartą na AGSSOM, która zatrzymuje usługi podczas procesu aktualizacji. Sprawdź AGSSOM, jest całkiem sprytny. Oto niektóre z C #, którego używam do tworzenia kopii zapasowej bieżącego FGDB, zanim go zdmuchnę:

// Only archive it FGDB already exists, if this is first run, then nothing to archive
            if (Directory.Exists(String.Concat(c.fgdbDir, @"\", kvp.Key[0], ".gdb")))
            {
                c.msg = String.Concat(Environment.NewLine, "Archiving data for ", kvp.Key[0], " - ",
                                      DateTime.Now.ToString("MM/dd/yyyy hh:mm:ss tt"));
                Messaging.Log(c.msg, c.lw);
                // Create the FGDB folder in archive dir if not already there
                if (!Directory.Exists(String.Concat(c.fgdbArchiveDir, @"\", kvp.Key[0], ".gdb")))
                {
                    Directory.CreateDirectory(String.Concat(c.fgdbArchiveDir, @"\", kvp.Key[0], ".gdb"));
                    // Now copy from clips to archive
                    foreach (FileInfo fi in source.GetFiles())
                    {
                        fi.CopyTo(System.IO.Path.Combine(target.ToString(), fi.Name), true);
                    }
                }
            }

Po prostu używa Directory.CreateDirectory i FileInfo.CopyTo, aby skopiować FGDB - Windows widzi FGDB jako kolejny folder. Działa jak mistrz. Następnie, po zakończeniu procesu aktualizacji, ponownie uruchamiamy usługi za pomocą aplikacji opartej na AGSSOM.

Chad Cooper
źródło
To było niezwykle cenne!
mogollon22