No, you do not have a name collision. Your DB_DOMAIN, DB_NAME, and INSTANCE_NAME can all be identical as long as the databases are on different hosts (as you have indicated). However, as others have stated using the same DB_NAME is a bad idea for anything other than perhaps a recovery operation. A policy enforcing distinct passwords will be broken. Connections will be confused. Most things you can do to ensure that changes are not inadvertently made on production are probably worth the hassle.
Here is the relevant documentation:
DB_DOMAIN
In a distributed database system, DB_DOMAIN specifies the logical
location of the database within the network structure. You should set
this parameter if this database is or ever will be part of a
distributed system. The value consists of the extension components of
a global database name, consisting of valid identifiers (any
alphanumeric ASCII characters), separated by periods.
Note: Oracle recommends that you specify DB_DOMAIN as a unique string
for all databases in a domain.
This parameter allows one department to create a database without
worrying that it might have the same name as a database created by
another department. If one sales department's DB_DOMAIN is
JAPAN.ACME.COM, then their SALES database (SALES.JAPAN.ACME.COM) is
uniquely distinguished from another database with DB_NAME = SALES but
with DB_DOMAIN = US.ACME.COM.
If you omit the domains from the name of a database link, Oracle
expands the name by qualifying the database with the domain of your
local database as it currently exists in the data dictionary, and then
stores the link name in the data dictionary.
DB_NAME
DB_NAME specifies a database identifier of up to 8 characters. This
parameter must be specified and must correspond to the name specified
in the CREATE DATABASE statement.
If you have multiple databases, the value of this parameter should
match the Oracle instance identifier of each one to avoid confusion
with other databases running on the system. The value of DB_NAME
should be the same in both the standby and production initialization
parameter files.
INSTANCE_NAME
In a Real Application Clusters environment, multiple instances can be
associated with a single database service. Clients can override
Oracle's connection load balancing by specifying a particular instance
by which to connect to the database. INSTANCE_NAME specifies the
unique name of this instance.
In a single-instance database system, the instance name is usually the
same as the database name.
You don't want them to be running with the same parameters in the first place. Very likely that you want to enable the 11g features. Things that you might want to make sure to be at least equal size are the memory footprint, temp tablespaces and undo tablespaces.
In Oracle 11g you might be tempted to use Autmatic Memory Management. There are some issues with it so it might be smarter to configure your shared pool and database buffer according to the 10g database. In the run check if you are not over or undersized.
Best is to hire a dba to help you with the setup, next best is to dive into Oracle® Database 2 Day DBA 11g Release 2 (11.2) There is a lot to learn from.
Best Answer
Instance caging is a feature in the Enterprise Edition of Oracle Database 11g Release 2 (11.2) that simplifies the management of CPU usage in consolidation environments. By enabling Resource Manager and setting the CPU_COUNT parameter in each instance, you can limit the maximum amount of CPUs/Cores the instance can use. You have to notice three points for this.
1. Enabling Resource Manager Resource Manager has been available in the Oracle database. Resource Manager is not enabled by default, so it must be enabled by specifying a resource plan before instance caging can take effect.
If you have no specific resource management needs within the instance, the simplest solution is to use the default plan.
2. Setting CPU_COUNT
3. Monitoring Instance Caging
The throttling effect of Resource Manager can be displayed using the CONSUMED_CPU_TIME and CPU_WAIT_TIME columns of the following views. The CONSUMED_CPU_TIME is the number of milliseconds of CPU time consumed by the consumer group, while the CPU_WAIT_TIME is the time waiting for CPU due to Resource Manager throttling.