From what you wrote, it sounds like you're performing an upgrade of ArcSDE and of Oracle. Based on the info you provided, I think the proper course of action is to perform the geodatabase upgrade first using the Esri tool Upgrade Geodatabase and then perform the Oracle upgrade second. You appear to be in an unsupported configuration anyways (with Oracle 22.214.171.124 and 9.3. SDE), so I would avoid upgrading the RDBMS platform until your version of ArcSDE is more in line with the system requirements from Esri. Before doing ANYTHING though, please back up your database using RDBMS tools so that you have a recovery point if something goes wrong. You should also perform these steps in a test database using a fresh copy of production data BEFORE attempting this in production.
To address the specific methodology you suggested in your post first... you are technically creating brand new object classes in your target geodatabase when using Copy or Import or any tool for that matter. Your target geodatabase has an entirely separate (and newer) instance of ArcSDE, and migrating data from one enterprise geodatabase to another in this specific fashion does not honor certain properties like archiving and versioning. Put differently, you will have to right click each dataset to enable archiving and to register their object classes as versioned just as you did in your source geodatabase. I think the sequence would be to (1) migrate all of your data first, then (2) register your data as versioned (without the option for moving edits to base), and then (3) enable archiving.
That being said, I don't think that is the best practice is to go that route especially if you ARE performing an upgrade rather than maintaining two instance of ArcSDE. I think the best practice is to perform the geodatabase upgrade first using the Esri tool Upgrade Geodatabase and then the Oracle upgrade second, as mentioned before. The geodatabase upgrade process that Esri provides with their upgrade GP tool should respect the versioning and archiving properties that you've already specified. One additional recommendation that I would have is to go directly to 10.1 SP1 rather than just 10.1. There were some issues with the upgrade tool at 10.1 that were addressed with service pack 1.