Hi Jesse, Am I correct in understanding that you're saying that particular update took over a week? That seems a bit extraordinary but I have seen where some updates like this are better off broken up into chunks or run serially for best results. The best path will vary based on system level, well, variables.
Rogan Hamby, MLIS Data and Project Analyst Equinox Open Library Initiative phone: 1-877-OPEN-ILS (673-6457) email: ro...@equinoxinitiative.org web: http://EquinoxInitiative.org On Fri, Mar 23, 2018 at 3:16 PM, Jesse McCarty <jes...@burlingtonwa.gov> wrote: > Hello Everyone, > > > > During my last test cycle we ran into an issue upgrading from 2.10 to a > newer version with an update script that was setting the 901$sfor bib > records. This took an extended amount of time to complete. Well now, in > testing our upgrade to the 3.0 series part of the 3.0.2-3.0.3 version > upgrade script took over a week to finish in testing, which is a big issue > for updating production. > > > Is it possible to comment out/remove the offending part of the upgrade > script and not have any issues with the new system after the upgrade? Could > it be the last part of the script in lines 277-291 of the upgrade script > taking this long (line 290 perhaps)? > > > 277 UPDATE biblio.record_entry > > 278 SET vis_attr_vector = biblio.calculate_bib_ > visibility_attribute_set(id) > > 279 WHERE id IN ( > > 280 SELECT DISTINCT cn.record > > 281 FROM asset.call_number cn > > 282 WHERE NOT cn.deleted > > 283 AND cn.label = '##URI##' > > 284 AND EXISTS ( > > 285 SELECT 1 > > 286 FROM asset.uri_call_number_map m > > 287 WHERE m.call_number = cn.id > > 288 ) > > 289 UNION > > 290 SELECT id FROM biblio.record_entry WHERE source IS NOT NULL > > 291 ); > > > > > > Wondering if others have met something similar and how they dealt with it > so as not to cause issues upgrading a production system and minimizing down > time. We typically run our upgrades on a Sunday morning and all Evergreen > related services are only down for about half a day and usually back up > before 10am Monday worst case. > > > > Thanks in advance, > > > > Jesse McCarty > > City of Burlington > > Information Systems Technician > > >