6TB Migration Project Issue - Select statement that is hanging the server after migrating 2 volumes

asked on May 4, 2018

HAPPY FRIDAY!!

So the last two Thursday evenings I have migrated 2 different volumes. And Friday come 9 am the app server service "Network PowerSnap Service" stops and once it is restarted the web server is still showing communication errors and prod is stuck. A DBA saw the outage notification that I post and checked the database and saw that a select statement that was blocking some others: select vol_id, storeid from deletedpage

Volume 1 we migrated - we did the folder, then searched all files that pointed to the vol and migrated them all. We then DISABLED the old volume. This was the IT volume so we had folks testing afterwards for a week until last night (Thursday) we did another, Volume 2.

Volume 2 - we migrated only the docs in the folder. After a search there are still files tucked in other volumes that we did not migrate. We have NOT disabled Volume 2 yet.

My question is this... Any idea(s) what could be causing the hang up? Is it possible it is getting hung up because we have files in the recycle bin that point to those old volumes, or even just Volume 1 that is disabled?

Any assistance greatly appreciated!! We have a long road ahead of us and having the server go down every Friday and even more frequently when we step up the migration schedule... Spring cleaning is lovely :)

0 0

replied on June 13, 2024

Hi Sue,

Were you able to solve this problem?

Checking my SQL Server I noticed that this query is constantly running on my instance and consuming a lot of resources.

I would really appreciate your help.

Regards,

0 0

replied on June 13, 2024 • Show version history

When documents and pages are deleted from the repository, they aren't immediately removed from disk - you may have seen other threads asking about this process. There is a background deletion task that runs periodically that actually performs the file deletion. It's what is running the query "select vol_id, storeid from deletedpage" to find items that have been marked for deletion but haven't been removed from the file system. It's a very simple query, so it's surprising that it is taking a lot of resources. Though due to the purpose of the table, if there is a problem running the query the table will only grow in size, and things may pile up from there.

I'd start by looking at the size of the deletedpage table - how many rows are in there? Can you run the select statement from SQL Management, or does that time out also? What if you tried to query just a few rows: "select top (100) vol_id, storeid from deletedpage". Are there any relevant errors logged in the event log?

To tie it back to the main topic - this background deletion process isn't directly related to volume migration. These pages and edocs are no longer part of any entry, and so won't be included in any entry migration.

0 0

Question

Question

6TB Migration Project Issue - Select statement that is hanging the server after migrating 2 volumes

Replies

Sign in to reply to this post.