Quelle est la bonne façon de sauvegarder une géodatabase fichier ESRI publiée sur ArcGIS Server?

11

J'ai une géodatabase fichier ESRI (v10) qui est publiée sur un service de carte de serveur arcgis. Lorsque le service est en cours d'exécution, la fGDB est verrouillée. Dois-je arrêter le service pour obtenir une sauvegarde propre? Ou, existe-t-il un moyen d'effectuer une sauvegarde via un script arcpy ou via le catalogue? J'utilise actuellement Windows Robocopy pour transférer le fGDB sur un lecteur de sauvegarde. Voici la sortie montrant les fichiers verrouillés:

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

etc...

arcgis-server esri-geodatabase mogollon22
la source

Réponses:

4

Tout serveur doit avoir un lecteur caché. Vous pouvez utiliser le «lecteur caché » pour compacter la géodatabase fichier et cela supprimera les fichiers .lock et réorganisera le fichier de la manière la plus efficace. Ensuite, vous pouvez sauvegarder ce fichier. Voici un bon couple de bons points de départ:

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

Remarque: Le lecteur fantôme a un autre nom de mise en miroir de disque

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

Mapperz
la source
Ah, j'ai toujours supposé que le compactage était pour les géodatabases sde. Merci!
mogollon22
Je gère plusieurs serveurs et aucun d'entre eux n'a de lecteurs fantômes ou en miroir, bien qu'ils aient des disques redondants (RAID5, Drobo) et puissent survivre à la panne d'un ou plusieurs disques sans perte de données. Quoi qu'il en soit, hormis cette objection, je copie les fgdb avec xcopy(ou xxcopy ), en ignorant les échecs, puis compacte le résultat. Ce n'est pas la meilleure solution car une classe d'entités verrouillée à cause d'une session d'édition pourrait être corrompue, mais ce n'est pas différent d'un lecteur miroir / miroir.
matt wilkie
2

Nous avons plusieurs applications Web de production à haute utilisation qui s'exécutent sur des FGDB sur le backend. Les FGDB sont effacées et reconstruites avec des données fraîches tous les soirs. Nous avons une application de console .NET que j'ai écrite qui est basée sur AGSSOM qui arrête les services pendant l'exécution du processus de mise à jour. Consultez AGSSOM, c'est assez lisse. Voici quelques-uns des C # que j'utilise pour faire une sauvegarde du FGDB actuel avant de le souffler:

// 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);
                    }
                }
            }

Il utilise simplement Directory.CreateDirectory et FileInfo.CopyTo pour copier le FGDB - Windows voit le FGDB comme juste un autre dossier. Fonctionne comme un champion. Ensuite, une fois le processus de mise à jour terminé, nous redémarrons les services à l'aide de l'application basée sur AGSSOM.

Chad Cooper
la source
C'était extrêmement précieux!
mogollon22