It sounds like you say "Sprint Goal" and mean "a really big bit of something the product needs to do that it currently doesn't." This can be a separate discussion of how to craft better Product Backlogs including Epics, themes, story maps, etc.
For now, here are things to focus on improving:
- Gain better understanding of Sprint Goal
- Spend time removing impediments to decomposing work into more manageable sizes
- Craft Sprint Goals based on work that can be accomplished in a single Sprint
I can help you with #1 :D
First, the Sprint Goal does not exist in the Product Backlog. Per the Scrum guide, a Sprint Goal is
...an objective set for the Sprint that can be met through the implementation of Product Backlog.
The Sprint Goal is crafted by the whole Scrum team (read: Product Owner, Development team and Scrum Master) after the Development team forecasts the work it can get done in the coming Sprint. The Sprint Goal may then be understood as:
...an objective that will be met within the Sprint
through the implementation of the Product Backlog, and it provides
guidance to the Development Team on why it is building the Increment.
Here's a visual representation of how a Scrum Team might handle forecasting work from their Product Backlog, form a Sprint Goal, react to unforeseen work, and still achieve their Sprint Goal:

If the Product Owner is unable to define work in the Product Backlog for which the Development Team can forecast completion in a Sprint, do not say/do the following:
- Lengthen the Sprint
- Say, "Scrum just can't work here"
- Take work into the Sprint that the Development Teams cannot finish
Ironically, shortening the Sprint (Product Owner decision) will many times force Scrum Teams to find innovative ways of producing smaller chunks of valuable, working software.
Instead, ask "what would need to change?" This constructively leads discussion towards the art of the possible which in turn inspires us to work for change.
Take only work into a Sprint that the Dev. Team thinks it can accomplish. Doing otherwise invites death marching (shudders).
Producing working software in 30 days or less is one of the most important aspects of agility that Scrum teachs. Please consider making these improvements a top priority for the health of the team and the organization.