They will do other work that needs doing. Keep in mind that "being in the sprint" means that the story is important. Not being in the sprint means the story is not that important.
Looking for something that falls in line with a person's specialty is nice, and making sure that over the long term your team's capabilities align with the kind of work requires is a good practice.
However, in the short term, if in this sprint there happens to be no work that relates to someone's specialty, it means you need to make a choice. You've basically got two options:
A) let them work on something that is important but they cannot do as fast as their specialty
B) let them work on something that is not important but they can do full speed
Generally speaking, the solution here is to focus on what matters. Remember that being agile is about delivering the most value, not doing the most work.
If that means your database expert spends a few days building forms, or your UI specialist is building some test data, that's probably more valuable than having them make things that aren't important right now. It means you'll be able to deliver the big and important features at the end of your sprint. It means your team will be focused entirely on one thing and everyone will be working together, towards a common goal. And it means still having the expertise of these people available when it is needed, because they are not assigned "non-sprint-goal" tasks that they are expected to complete, thus making it more difficult for them to drop what they are doing to help out with what is important.
See also the Resource utilization trap. What matters at the end of your sprint is not how efficiently people work, or how code was written. You need to measure throughput, not effort. And you maximize throughput by doing what is important, not by doing what you're best at.