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...

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


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.


To było niezwykle cenne!
mogollon22
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.