* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download ArcSDE
Survey
Document related concepts
Microsoft Access wikipedia , lookup
Oracle Database wikipedia , lookup
Serializability wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Functional Database Model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Relational model wikipedia , lookup
Versant Object Database wikipedia , lookup
ContactPoint wikipedia , lookup
Transcript
ESRI User Conference 2004 ArcSDE Some Nuggets Setup Performance Distribution Geodatabase History Setup Initial Database – – Create as large as possible to avoid fragmenting indexes Set growth rate to a large value for same reason Fillfactor – Set very high for read only environments – Set midrange for editing environments 95-100% 75% default Users – – 9.0 supports Windows groups but they can not own data Windows groups are more efficient than individual logins ArcGIS checks sysprotects table for permissions Setup (cont’d) Permissions – Data Loader – Data Editor – Create Table Create View Create Procedure Select Insert Update Delete Execute Use ArcCatalog to assign permissions Associated tables may be missed if using DBMS to assign permissions Setup (cont’d) Logfiles – User logfiles – Session logfiles (recommended for SQL Server) – An individual logfile table is created once for each user An individual logfile table is created and destroyed for each login session Maxlog = 0 Allowsessionlog = true Logfilepoolsize = 0 Pooled logfiles A series of logfile tables are created once Each login uses one of the pooled logfiles Need to provide enough tables for all logins Setup (cont’d) Upgrading – – – – – – – – – – Backup Uninstall 8.3 Install 9 run checkschema.exe – 25 errors at a time max. run custom post-installation – don’t create new dbase or SDE user if upgrading run migratory sample utility – to convert each spatial database to a series of single standalone spatial databases Create new service for each single spatial database Recommended storing rasters in a separate database Only store separately if they are completely separate (no cross database queries supported) Follow up migration with sp_change_users_login to synchronize ID’s Performance Memory – – – – Make sure dbinit.sde is empty unless debugging – Initially set SQL Server memory to 50% RAM and move up from there Setting SQL Server memory too high will restrict gsrvr.exe 1 giomgr.exe is spawned at runtime 1 gsrvr.exe is spawned for each connection Stores detailed initialization information Set TCPKeepAlive to ON to close orphaned gsrvr.exe processes Performance (cont’d) Reference Classes – – Only use during editing All reference classes need to be loaded when used and this sucks up memory Excess number of privileges will slow things down Servers start queuing SQL statements when they hit 65% CPU usage Index Tuning Wizard – Use to check often used queries for performance Performance (cont’d) Loading – Set the recovery model to simple – Avoids tracking everything when you don’t need to rollback Turn off the transaction logfile when loading Bottlenecks – – – Server processor should never exceed 80-90% capacity Memory buffer cache hit rate should always be below 90% Average disk queue length should not exceed 2 Performance (cont’d) Logfiles (check these) – – – – Giomgr.log – client connection information Sde.log – detailed error logs Sdedc.log – direct connect information Upgrade.log – patch information Compress the database at least once a week The single most important thing that will effect performance of your geodatabase is: The # of states for a version (Lineage) Distribution Geodatabase Replication – Single Generation (9.0) (a.k.a. Disconnected Editing) – Check out from one versioned GDB to another Check changes back into original Multi Generation (9.1) 1 way replication – Used to replicate read only data (mirror) – Only pumps changes to the child database 2 way replication – – – – – Changes can be sent both ways Allows to independent sites to edit data and exchange edits Uses a Global ID (GUID) on each feature Works on specific versions Synchronization Process (Parent wins, Child wins, Manually Reconcile) Distribution (cont’d) Replica Agent (9.1) – Allows setting up a scheduled task to determine when changes move between the databases They are developing a web service based way of automating change movement – Enables disconnected synchronization Geodatabase History Store changes over time using versions (9.0) – – – – – History of the DEFAULT version of the database Developer sample for inspecting the history of an individual feature (“a feature’s lineage”) (-) Historical versions cannot be edited (-) Significant performance hit if require finegrained history (i.e., OK for snapshot archiving, not OK for transaction level archiving) (-) If schema changes, history is lost. Geodatabase History (cont’d) A Transaction Level History Solution (9.1) – – – – Each feature class (FC) has an associated history table (e.g., Parcel_history) …identical to business table (except includes “in date” and “out date”) (+) History not lost with schema change. (?) Performance (-) Does not capture change in related tables Geodatabase History (cont’d) Version Log (9.1) – – Compare two versions and show me the differences. Useful for situation where workflow dictates that another person review the edits before committing them to the database.