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

This widget could not be displayed.

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
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted yesterday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

78 views 1 0
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