integrity check and indexing

We have the choise of running Background re-index or Lock JIRA and rebuild index. We have discovered that running Background re-index often causes trouble/problems for projects and they often stop working whilst the process is running.

What is Atlassian's advice for this? Is it better for us to perform Re-index project on the actual project that needs it after changes and can this action help us to avoid running a big indexing?

We now run an integrity check first followed by the Lock JIRA alternative to be sure that we do not cause problems for our projects. What is your recommendation?

1 answer

0 votes

Start with the question of why this causes you a problem.  Re-indexing should be infrequent, and only really triggered when an admin is making field changes or has run into system problems.

A project re-index will do the basics if you're making field changes, assuming the field is limited by its context to that project.

Thanks for the answer.

We are making a lot of changes in the system and therefor needs to re-index periodically. We feel that the system slows down and even losese contact when we do the background index.

So if we stick to the fact that if we make a full indexing to the system (not in the background) and thereafter always run a project re-index when we make changes we should be fine? (And then not get the annoing message up to the right that suggest we perform indexing)

Yes, indexing is an intensive process that chews up a lot of resources while it runs.

The advantage to project re-indexing is that it only does a sub-set of issues, so the process thrashes your system for a shorter time.  The background re-index can be thought of as "get list of projects, and click on re-index for each one, one at a time".

Can I please check with you what the difference is between these two ways of running indexing?

There's more than two ways of indexing.  It's not quite this simple in reality, but unless you're coding, this is the easiest way to think of it:

  • There's a chunk of code which reads the index for an issue.
  • There's a chunk of code which reads an issue out of the database and creates a set of index entries for it, based on the "searcher" code for each field and attribute.
  • When JIRA needs to index a single issue, it runs the "read index" code above, removes the existing data it finds for that issue from the index, then runs the "create" code for it.
  • When you ask JIRA to run a project index, it does a SQL search for "all issues in this project" and runs the create code for each issue.
  • When you ask JIRA to run a full background index, it does a SQL for "all issues" and runs the create code for each issue.
  • When you ask JIRA to run a full locking index, it throws away the whole index and does a SQL for "all issues" and runs the create code for each issue

OK - thanks for this very explaining answer

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Sep 25, 2018 in Jira

Atlassian Research Workshop opportunity on Sep. 28th in Austin, TX

We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...

465 views 7 5
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you