"I think the main issue with the stored procedures is that the designer executes all of them with default values to see if they're returning a resultset. That's on one of the tabs in the wizard you go through. If your stored procedures do a lot of work with the default values but not with others, change the default values for the various parameter types on that page in the wizard. Or if you don't have any retrieval procedures, UNCHECK them on that tab." This is sadly something that's unavoidable IF you want the designer to determine if a stored procedure returns a resultset and what the shape of that resultset is."

We have around 350 stored procedures in our project. Some of them are action procedures (which do not return a resultset), while others are retrieval procedures (which do return a resultset). Each time we refresh , we have to review all of their schemas during the retrieval process, which becomes quite time-consuming.

As explained in my reply, and documentation, if you need the shape of the resultset (so which columns are in the resultset) the stored procedure needs to be executed. In oracle, we can also determine if a stored procedure returns a resultset by checking if it returns a cursor. So if you use untyped resultsets in your model (so they're fetched to datatables), you can uncheck all stored procedures on oracle.

If you have typed constructs mapped to the stored procedures, you have to check why executing them with the default values as defined in the relational model retrieval wizard (which is the wizard you go through when refreshing the catalogs) on the tab of the stored procedures takes such a long time. executing 350 should take no time at all, so that it takes a long time is something only you can check;

If the stored procedures in the schema will consume massive amounts of data when executed, it's best to recreate the schema without any data and refresh with that schema. But above all, first check why it takes such a long time to execute these stored procedures in a transaction.