August 20, 2013 at 10:51 am
Woops... I was wrong... our db is on a different SQL Server.... SQL2008 R2 SP2.... still should be hitting that integrity check bug for spartial index...
August 20, 2013 at 10:53 am
I think you should be fine since it's SP2 not SP1 (pre 10.50.2796.0)
August 20, 2013 at 11:00 am
HildaJ... You are correct I am good to go... I am getting confused on what version and service pack the bug fix is in... AND even what SQL Server I am running the db on. I have two 'like' servers and one is SQL2008 and the other is SQL2008 R2. With all of the dbs I have I can't keep track of what all dbs are on which installation. LOL
Very good, detailed article thanks for posting. The community always appreciates these types of little articles that may stump others as they may run into the same issue.
August 20, 2013 at 1:38 pm
Thanks for a good article Hilda.
I have been hit by different server versions ourselves causing odd behaviour introduced by a service pack. STUnion started returning lines when combining 2 polygons. This of course only showed up in Prod, as Test hadn't been patched
andrew.neuman (8/20/2013)
How has your upgrade been to ArcSDE 10.0? We are still using ArcSDE 9.3 but, I know there are some fundamental changes that occur there. The largest being that the geometry storage has changed from ESRI's format (SdeBinary) to native SQL Server Geometry format. The biggest gotcha I see for the DBA perspective is that spatial indexes are no longer created on the GIS side, so they need to be created on the database side.
I have done a few migrations from 9.3.1 to 10.0 and recently one from 9.2 to 10.0 (was nasty). All I can say is be methodical and calm. Test each step and take backups between each one. A backup of the SDE geodatabase to a File geodatabase might be a good idea, I would use a 10.0 version of Arc Catalog to do this (it should talk with SDE 9.3).
Make sure you are using the right datatype for your data (Geography for Lat/Lon, Geometry for cartesian). If you are using geometry, make sure that the spatial indexes have a sensible extent defined.
Thanks for mentioning GIS, in my organization GIS is one of my heavily used databases and people tend to forget that it's stored on the same server as the rest of the databases and until recently people also treated it as something completely different than what it is... Just a database
Couldn't agree more, the geometry is just another chunk of data in the row and should be subject to the same rules and policies as other data. Unfortunately some of us GIS people/organisations tend to forget that.
August 20, 2013 at 2:39 pm
Managing a production database environment is a delicate, sensitive, and vexing at times. I sympathize with you on the upgrade issue you had and which you so well described as I think any DBA would.
I suggest setting up a checklist that includes your daily database administration routines activities will alleviate the need to juggle competing priorities as a DBA. The checklist would typically include tasks such as reviewing server and database logs, setting up new and monitoring scheduled jobs, monitoring disk space usage, setting up and managing security, installing patches, implementing change requests, deploying builds, monitoring and troubleshooting queries performance, resolving outstanding tickets, answering routine requests, and as it may be necessary, planning for major upgrades (application, database, service packs), writing standard operating procedures and policies.
The checklist is by no means exhaustive and can be expanded upon. Once the list has been reviewed and you have secured the appropriate sign offs, I recommend sticking it on the wall in your office or cubicle right next to where it can readily be seen.
In addition, allocating a time slot to each task on the list would help pace yourself, save time, and eliminate potential errors and omissions.
I appreciate it you sharing this story.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply