First, the method hides what it's really doing in the signature. Imagine the following situations:

int value = 5;
int result = GetDBInt(5);

From an optimization point of view, this is silly. You're taking a value that's already of the correct type and converting it to a string so you can convert it back again. Pointless.

How about this:

double value = 5.1;
int result = GetDBInt(value);

In this case, TryParse will fail because 5.1 is not a valid int. What you probably don't realize is that your method WILL NOT return -999. The TryParse method WILL assign a value to the output parameter regardless of the the fact that it failed to parse the string. The actual return value in this case will be 0 (the default value of int).

Okay, so now let's consider what you're probably using these methods for, to parse strings.

string value = "5";
int result = GetDBInt(value);

This case will work as expected, the return result will be 5.

With these things considered, you might find that the methods are not really dependent on "object" types, but in fact expect strings. It might be more appropriate to change the method signatures to take strings instead, that way you are not hiding the fact that the objects are turned into strings first anyway.

At this point, the ToString's can go away, and the null check's become redundant. The method actually reduces to a simple wrapper around TryParse and will return the same results as your original methods. (it will return 0 for null, or any other invalid value).

At least this way, the caller can decide what value they want if the database doesn't have it.

string value = "x";
int result = GetDBInt(value, 15);

Lastly, your question is actually about optimization. However, I'm willing to bet that these methods are not the biggest bottleneck in your program. If you ran a profiler over it, they probably won't even show up on the radar. Try not to fall into the premature optimization trap. Focus on working code, and profile it afterwards.