Copy is the only built in function that will do this that I have found, but you are restricted to transferring all Spatial and Attribute settings the same into the target database. Feature datasets may have to be copied in their entirety in some cases.
All other methods, such as using Export and Load to create a new schema or Spatial Reference, always rebuild the OID values. The internal tables that perserve the OIDs for the copy method are not exposed by ESRI to end users through any methods I know of and they are not inclined to let users access these internal tables directly for fear of all the bugs that we would create (and that ESRI willl not support us in resolving).
For all methods other than copy, the old OID values must be preserved into another LONG field on the output to the new gdb, so far as I know. That long field can be used to join the target data back to the original. A number of methods can be used to do that if you cannot modify the original schema to add the field and calculate the OID values to it. This method can be used for rebuilding Feature-Linked Annotation to connect to a new Linked Feature-Class converted to a new Spatial Reference and Schema (I just did it 3 times in the past 3 weeks and finally got a method that worked in about 2 hours for a large SDE dataset with 5 Feature-Linked Annotations that had to be copied twice and reregistered with new permissions.)
Even if you use copy to transfer the old OID values to the new gdb, if you make additions and deletions of records to both the oriiginal and copy independently they will not stay in synch. If synchronizable editing in both the original and copied data is part of your operation, look at using global IDs and Replication through the Distributed Database toolset.
