Let's suppose a Product Owner added a big User Story to Product Backlog in Jira. This User Story can't be done during a Sprint or even during several Sprints. How do we refine such a User Story in Jira? Do we delete it and create several smaller User Stories instead of this big one?
Although Product Backlog Refinement is the method by which the team ensures that the Product Backlog Item can be completed within one Sprint and has all of the necessary attributes (such as description, order, size, and/or value). However, since Scrum doesn't mandate the use of any particular tool, it doesn't tell you how to go about using any tool.
Jira gives you a few options.
First, you can make that big story an Epic. By doing so, you can get some visibility into the issues that are children of that Epic, including Stories. You can also use the roadmapping features that are now built into Jira or the planning features (formerly Jira Portfolio) if you have the Premium edition. However, Jira defines an Epic as a container for other work. This isn't the more traditional definition of an Epic, a User Story that has not yet been decomposed.
Another option would be to make more User Stories. Begin to split out work into new issues of the appropriate types. You can optionally link the issues with the right relationships. In fact, Jira even has link types for "is included by", "includes", "split from", and "split to" for this type of work. In the end, you may end up closing (or deleting) that too big Story or you may end up editing it to be a smaller piece of the work.
A third option would be to leave that User Story and use subtasks to represent the work that fits into a Sprint. In this model, the User Story may not be done in a single Sprint. However, you'll understand when all of the work is done by seeing all of the subtasks' status.
There are probably other options, too. Jira is highly customizable and configurable, and even more so if you have different plugins. There needs to be some level of melding between your process and the Jira configuration.
Consider having a meeting, called Backlog Refinement, that you run before Sprint Planning. Both a developer and the Product Owner must attend.
During the Refinement meeting, you go over the Stories and do a sanity test, ensuring they fit the INVEST method.
If you don't want to have a Refinement meeting, this can be done during Sprint Planning as well. However, make sure that both the Product Owner and developer(s) are involved.
If there is a need to provide one huge story in one sprint, there is only option to either fit it in one sprint, or to call it a Feature and then decompose it to smaller business stories, then to tasks.
Anyway, if 'one business story' in its entirety cannot be fully designed, developed and delivered in one sprint - it cannot be tested correctly, because it has to be verifiable and testable. The result of the sprint should bring a business value - a part of a business story does not bring a business value.