Recommendations on modifying database maintenance schedule to eliminate or minimize end-user performance hits in document retrieval, scanning, indexing, etc... during db maintenance?

[Nick_Nichols]

I am looking for specific recommendations on modifying database maintenance schedule to eliminate or minimize end-user performance hits in document retrieval, scanning, indexing, etc... during nightly db maintenance.  We recently went 24/7 for end-users accessing OnBase with our Epic implementation, and our 3rd shift users are consistently taking performance hits for 15-45 minutes about 15 minutes into the nightly db maintenance jobs starting.  I have seen a handful of posts where folks have had to carve out certain tables to re-index / update stats on different nights / weekends as a mitigation strategy.  I'd like to have specific advice on which tables to carve out for different maintenance schedules and any other mitigation strategies to get around the db maintenance performance hits? I know the DB Reference Guide provides general guidance, and gives quite a bit of leeway/flexibility for DBAs to design and implement backups and table maintenance, but I'm looking for tangible, specific recommendations from other customers who have encountered the problem, and have developed a workaround or best practice (e.g., Table ABC index rebuild and update stats occurs weekly on Sunday night, Table DEF occurs nightly, Table XYZ occurs etc.... ). 

We are running OnBase 15.0.3.296, SQL Server 2012

Thanks in advance for any specific guidance and recommendations.  

[Bob_Shepherd]

Nick,

We are also looking for that same guidance.  Has your team had any luck since this post?  We have a 1.4TB database and the performance impacts to end users are very noticeable when we are running maintenance.  We tried only updating stats once a week but that had a negative impact on our rrjob table so we are trying to find the "sweet" spot.