Harvard Wiki has been integrated with Group Services.
Wiki administrators: visit IT Help for an overview of the changes to managing groups in your wikis.
Skip to end of metadata
Go to start of metadata

1/31/17 check in

attending: Dave, Randy, Sharon, Tom, Benson

Meeting NOTES:

Action items:

  1. The PROD DB is migrated to 11g on Mercator, Dave has performed the schema upgrade, and Venu is about to update to 12c.
  2. Dave will ask Venu to backup the DB before upgrading, so as not to risk losing his work a second time.
  3. Dave/Tom will check database size on Mercator. If its only 1700GB like on alcott, we will shrink disk mounted to 2000GB on mercator
  4. Dave will figure out how much his projected disk space on mercator will be for the next 3 months, and request it be upgraded to that amount
  5. Assuming the 12c update goes well, Dave will start publishing data layers, benchmark the time, and let us know how long this is expected to take.

1/25/17 check in

attending: Dave, Randy, Sharon, Tom, Benson, Linsday, Anthony

I had written the notes below, when I just was copied on this email from Venu:

Hi Sunny,

I just confirmed from Vendor Esri the application is not supported for direct upgrade on 12c database.  So we have to revert back to 11.2.0.4.  Restore from good backup level 0 from Alcott HGLPRD  in  Mercator and bring up the database.  Please ensure there are no datafiles in backup mode.  Appreciate if this could be done on priority.  Thanks,

Venu

So action item 1 below is likely now to wait until they have reverted to Oracle 11.2 and do it there instead…  (Sigh… REALLY back to square 1 now…)

Meeting NOTES:

Action items:

  1. Dave will attempt the ArcSDE schema upgrade on the Oracle 12c instance on Mercator. If this succeeds, we will have all 14000 data layers (both raster and vector) for PROD migrated to ArcGIS 10.4 on Mercator.
    1. The remaining step, duration unknown, will be to run a python script to “publish” each data layer from Mercator so that it is available to the HGL user interface. For the 3500 raster and scanned map layers, the publication step will also delete the data from the database and store it in the standard file system on pelham. For the 10,500 vector layers, publication will not delete data from the database, but the size per layer is smaller than for raster.
    2. We would need to keep the full sized Alcott and Mercator databases for the duration of migration, unless we implement a more complex hybrid access process for HGL
  2. Dave will also write up a short statement of work for ESRI, and ask them for a quote to migrate the database and publish all layers.
  3. As a fall back if neither of the above succeed, Dave will plan how we could skip the Schema upgrade entirely, and use desktop tools to publish all raster and scanned map data layers directly from the old HGL database on Alcott to the filesystem on Pelham, as well as to publish/migrate all raster layers from Alcott to Mercator.
    1. With this scheme, we could immediately reduce the database size on Mercator to 300GB. We would not have to increase its size until all raster/scanned map publication was complete and we needed to start adding vector layers to Mercator
    2. diagram of plan. https://docs.google.com/drawings/d/1RSPVSPJze4aIsLWl1I12bc1XLhz0jQn_8OSryfWhTw0/edit
  4. I will schedule another checkin for around 1 week from today.

1/4/17 check in

attending: Anthony, Sharon, Tom, Benson, Dave, Randy

Action items:

  1. Sharon to switch storage on pelham from premium to standard. This will save storage cost on pelham.
  2. Tom will give Venu the 500GB more disk he is asking for to complete database migration on mercator.
  3. Dave will pursue ArcSDE 9.2 to ArceSDE 10.1 to ArcSDE 10.4 upgrade, followed by Oracle 11.2 to 12c upgrade on mercator
  4. Cost estimates attached.HGL costs, with estimates-1.xlsx

11/9/16 check in

attending: Anthony, Sharon, Tom, Benson, Dave, Randy

Action items:

  1. Reviewed this diagram, and discussed options for maintaining or improving performance, and related costs.     https://docs.google.com/drawings/d/1ZgqQsL4YLJm7zQ8Q1ve-KYmyVotDRv6ueOGETNSAZXw/edit?usp=sharing
  2. Here are the options we arrived at in our meeting. If Dave could fill in the “One time dev cost” column, and Tom could fill in the “One time ops cost” and “Annual cost saving” columns, we would have some useful data.     Cost saving options for HGL

 

 

  • No labels