We are struggling with finding time for IT to do system maintenance. We have not been able to find a good window where one shift or another is not scheduled to work. We have concluded that we will need to have people track their labor activitieson paper and then upload via DMT. We have been told that even if Data Collection is on another server people will still be bumped off when SQL server maintenance is done. I am curious as to how other businesses manage this?
Userlevel 3
Depending on what is being done, SQL itself shouldn’t be down that long - an hour? I’m usually able to apply updates to production machines fairly quickly.
If you are experiencing long times due to server reboots, make sure you are using virtual machines. These reboot much faster than physical machines and can save you a lot of time when doing updates.
Recording on paper is a good fallback. You may need this if you ever have a significant computer outage anyways. Good to have the plan in place. You can either enter these by hand into the system under Time & Expense, or you can DMT them in. Depends on what would go faster in your situation.
Also having test machines where you can apply the updates before production will give you an idea of how long the system will be down. This way you can try to warn people of the outage window or schedule the outage for the “least used” time window.
Thank you, Fred. Appreciate the advice.
Userlevel 4
What system maintenance is causing this issue? Are you doing Transaction Log backups on a schedule?
From your question, I am assuming you are on premise?
As far as I am aware there is nothing that should stop you from taking the SQL database down so that Epicor users cant transact!
Hello Sue,
Yes, we are on premise. We are kinda new to Epicor and need to do some of the following things: Shrink the production database so that we can refresh our test and pilot databases, add disk space, install patches, regen and recycle, and possibly other stuff (I am asking for our IT manager). We have been advised that operators cannot transact during these activities which is not making operations managers very happy. I am reaching out to anyone I can think of to see what other people do, hoping to discover some best practices.
Userlevel 3
EEK - DO NOT SHRINK YOUR DATABASE without knowing why it grew. BAD, VERY BAD habit to get into.
Install patches will cause downtime when you apply the patch. Again, do that on your test/other server or instance so you know how much time is needed and work to get it minimized as much as you can. Also, you don’t have to apply patches every time they come out. Only do it when the patch fixes something you need.
Regen - you should only have to do that when you add new fields to the database. You shouldn’t be doing that much after go-live. You can test how long the regen takes by doing that in pilot/test as well so you know the downtime. Usually this takes 10-30 minutes. There are people who do a regen without stopping the app pool so that people can continue to work. I have several clients who do this, but I’ve been told by a reliable source that this is not a best practice and may cause issues. You should always stop the app pool.
You can direct message me and I can get you some pointers on SQL management best practices. fred@codabears.com.
Its a transactional database, its primary job is to grow in size by storing transactions.
you need to invest in decent storage, no way out of that for the business it essential, not enough to just keep it going now but for the next few years, and as stated - do not shrink it, its a resource intensive task and your are also screwing up your indexes making everything even slower.
sql generally performs better by staying “up” longer, as execution plans etc are loaded to memory.
schedule patches for weekend nights etc if there is a free window, but a lot of patches don't need a reboot anyway.
i do the odd regen in live without stopping the app pool, some might experience a slight pause, but nothing else
Userlevel 2
Isn’t there one of the backup modes in SQL administration that eliminates something with a name like tail files, a nondestructive reduction of file size because it’s garbage collection? I haven’t done it in a while.
Userlevel 3
Under options on the database the recovery options are Full, Bulk-Logged, or Simple. With Simple you won’t have transaction logs to backup. Only good if you only want to restore to the last full backup and not a point in time. Bulk-Logged - don’t use this unless you know what you’re doing. Full - preferred option for production databases so that you can restore to a point in time. This requires transaction log backups.
None of those have to do with shrinking the database...other than you should do a backup before and after shrinking the database.
The important thing with recovery options is knowing how they affect your backups and restores and that you have a DOCUMENTED plan for how to do the restores when you need it. If you don’t know how to do the restore, when you are down is not the time to find out.
I wrote a whitepaper on this: http://digioh.com/em/20867/56106/3tbv9v4q2a
You can DM me if you have questions. Happy to help out.
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.