You need to add primary keys where possible to those tables listed in DBA_LOGSTDBY_NOT_UNIQUE. Then you'll need to mark any of those tables for which you cannot create a PK, and all the tables with ROWID columns, to be skipped by the apply processes. And if you want to propagate changes to those tables, do it by some other means: a periodic export/import, perhaps.
But this is only a work-around. The best solution would be to investigate why those tables contain ROWIDs and do not have primary keys, and fix them accordingly.
--
John Watson
Oracle Certified Master DBA
http://skillbuilders.com

It seems that you may be missing the point of this.
SQL Apply needs a primary key to identify rows. If there is no primary key, SQL Apply will fail. If you define primary keys with RELY DISABLE, the SQL Apply will not fail but it will corrupt your data (unless your application software handles the situation).
Perhaps some outside assistance for this project would be advisable.
--
John Watson
Oracle Certified Master DBA
http://skillbuilders.com

You said:
>
SQL Apply needs a primary key to identify rows. If there is no primary key, SQL Apply will fail.
>

That is not correct. SQL Apply will work in the absence of a Primary Key also - as long as the datatypes of the table are supported.

The LGWR on the Primary DB will in this case include all columns of the rows that have been modified into the Redo Stream, though.
That is why it is desirable to have Primary/Unique Keys on the Primary because it avoids these additional entries in the Online Logs.

Uwe Hesse wrote:
You said:
>
SQL Apply needs a primary key to identify rows. If there is no primary key, SQL Apply will fail.
>

That is not correct. SQL Apply will work in the absence of a Primary Key also - as long as the datatypes of the table are supported.

Well, maybe. I'm not about to test it.
As far as I can remember (10g was some time ago) my experience, with Streams more than logical standby, was that in these circumstances you can create an unconditional supplemental log group with all the columns, and it looks OK but eventually it will fail because the impossibility of identifying a unique row means that the data diverges.
So everything works for an hour, a day, or a month - but eventually it falls over.
But right or wrong, not having a PK is a seriously bad idea.