For point 1:

is it possible to move table between dbspace?

Not with a single statement. Cf that similar, but opposite question... - When using the "full unload"-approach to reload into a single-space database, you can simply use dbunload with the -kd option, i.e. there won't be a need to modify the created reload.sql file in-between.

For point 2:

can I assume 100 to 400KB pdf rows will not impact database performance?

The question is how much has the separate dbspace helped to improve performance. If it was one a different physical medium, it should have helped ("different heads in use") (*). If it was just a different file on the same physical medium, I guess you won't notice any disadvantage. Just my wild guess, apparently:)

(*) - Here's another discussion on the pros and cons of dbspaces.

> move table between dbspace

Check out this blog post from eight years ago: UNLOAD and LOAD Via Named Pipes.

It is used by Foxhound every time an older Foxhound database is migrated to a newer version. In Foxhound's case, the two different dbspaces are the SYSTEM dbspace in two different databases which is a harder problem than yours, but still possible using the FORWARD TO statement.

So, as proof that the named pipes technique works in production, for gigantic tables, here are some snippets from Foxhound:

DECLARE @sql   LONG VARCHAR;
...
SET @sql = 'UNLOAD TABLE DBA.rroad_group_2_property_pivot 
   TO ''\\.\pipe\data''';
...
SET @sql = REPLACE ( @sql, '''', '''''' );
SET @sql = REPLACE ( @sql, '\', '\\' );
SET @sql = REPLACE ( @sql, '\', '\\' );
SET @sql = 'FORWARD TO old_foxhound1 ''' + @sql + '''';
...
TRIGGER EVENT rroad_execute_immediate ( @sql = @sql );
...
LOAD TABLE rroad_group_2_property_pivot ( 
   sampling_id,
   sample_set_number,
   connection_number,
   ...
   ) FROM '\\.\pipe\data' 
   DEFAULTS ON;
...
CREATE EVENT rroad_execute_immediate
HANDLER BEGIN
DECLARE @sql    LONG VARCHAR;
SET @sql = COALESCE ( EVENT_PARAMETER ( '@sql' ), '' );
IF @sql <> '' THEN
   EXECUTE IMMEDIATE @sql;
END IF;
END;