The role is subject to a company's idea of what the role is and their definition is the only one that matters.
Will you support the underlying OS for example?
The person who can give you the best ideas is the person who had the role before or their manager if they are not available.
The application vendor can give you ideas if there is one.
Understanding the what, how and why of the existing install is critical.

Sign up for product alerts from Intersystems here
Consider getting your own instance here
Here is link for IRIS administration documentation

Yes there is a way since I have seen it.

The ZLOAD and ZREMOVE commands are combined. Here is a sample I was sent.

showAdmins() n rs1,rs2,rc1,rc2,$NAMESPACE,user,adminrole,roles
  s rs1=##class(%ResultSet).%New("Security.Roles:List")
  d rs1.Execute("*","%Admin_Manage:U,%Admin_Operate:U,%Admin_Secure:U")
  f  s rc1=rs1.Next() q:rc1=0  d
  . s adminrole=rs1.Data("Name")
  . s rs2=##class(%ResultSet).%New("Security.Users:List")
  . d rs2.Execute("*",adminrole)
  . f  s rc2=rs2.Next() q:rc2=0  w rs2.Data("Name"),"|",rs2.Data("Roles"),!
d showAdmins

Yes you could edit the database properties ^DATABASE so a particular database did not journal but I would be worried that the journals will also change the other datasets so I would unmount them before applying journals.

It might be better to create a parallel instance and mount the restored database and then replay the journals.

For a production issue I would reach out to the WRC.

The host, storage and DB engine don't influence the gref count at all. Only what the code does.
If you do a set,kill or write that is a gref.
The host, storage and DB engine determine the limit of grefs per second.
Faster storage is always better.
More memory (larger global/routine buffer) is always better.
Faster cores are always better. More cores are better if there is work for them to do.
Newer versions of IRIS (DB engine) are always better.

GLOSTAT will give you some numbers

Vertical Scaling IRIS