How do you handle being assigned Ops tasks knowing you joined to do Dev?

I'm going to first answer this question ignoring the fact that you joined Oracle. I'll address my feelings about Oracle later.

I would posit that in high functioning engineering organizations ever dev should get experience and in fact target a minumum of 1/3rd of their time be spent on operations work. Ignoring the way your application get's deployed, the environment it has to run in, the systems it needs to integrate with is a great way to build terrible software. Knowing all of that detail makes you a better developer and helps you develop better software. So I don't find it necessarily bad for your career if you end up doing some operations work as a developer. That said you do still want some level of actual development work present so if you don't have any of that then it's a sign of an unhealthy engineering organization.

Now to address the elephant in your comment. Since you mentioned you joined Oracle my advice is to get out as soon as you can. That company is toxic. It's a toxic presence in the database marketplace regardless of how good the database itself is. I've heard it's also a toxic place to work. No idea how much of the workplace stuff is true as opposed to just rumor but it's enough to convince me never to work there.

Yes, virtually every job I've had to at least do some Ops. I also had to do some management quite often.

I don't know what it is about the software industry, that simultaneously not many people can code well yet companies seem to not want programmers to just program. I feel every manager I have come across has somehow expressed a view that I needed to do much more than just code... at one place they even said it was "the bare minimum" to contribute to the codebase, but when I ask if the manager should expand their own horizons and do some coding, of course that idea never gets attention of any kind.

It does feel like unionizing might be overdue for software engineers across the industry.

If you want a change, leave. I wouldn't expect them to change just for you honestly.

I think most places will have you do a bit of operations work.

One thing you didn't mention is that you talked your manager or tech lead about your concerns. Before you write it off, I would definitely talk to them about your concerns. I would approach it as a "Hey, I'm OK doing this to get experience and help the team out, but I was expecting a bit more dev work." I think this is a good first step to make sure that you and your manager are on the same page for what you should be doing for your job. Like some of the other commenters said, it's OK to do some ops, but definitely talk to your manager and set your expectations for the job you signed on for.

I'm in the same boat. I'm handling it by looking for a new job.

You are absolutely damaging your growth potential as a developer.

Operations might give you some useful perspectives just like QA might give you some interesting insights but it won't be as helpful as actually writing code.

It sucks but we're in an industry that actively preys on the naivete of those with less experience.

Don't fall for it. Start looking now.

You will never be a developer at Oracle. If you are okay with that stay and if not leave.

It happens all of the time. You applied for one role and interviewed you and hired you a different role. Your job title and responsibilities made within your offer should mention this change. Were you hired as a developer with title or ops?

Nothing wrong with ops work, it's good to know how apps are run and deployed, as a backend dev I do both and I'm glad I do as it enriched my skillset and understanding of production software a lot more. Embrace it.

I'm not sure how someone would get a well-rounded understanding of IT without doing some ops work. I've seen a lot of obvious security issues because the developer had no experience with security.

A good team player would do them without complaint, with thorough communication, and a healthy positive attitude, but work with the stakeholders towards: first, documentation, then automation.

"everyone has a plan until they get punched in the mouth" -mike tyson

If you're not doing some work to understand how your software works in real life, you're just a theoretician, and you're going to get punched in the (virtual) mouth when your naive assumptions fail to materialize in the random world of production.

Do the ops work, just like Ops/SRE cleans up the shit-stew you call your software when it breaks in prod. Or stop writing bugs. You pick.

Saying you looked into it but don’t know what to do works wonders.