Before running the setup script, you should be aware of the following requirements:
The database user who runs the setup script is expected to be the same one used to update the MobiLink system tables during synchronization. This user must be used to start the MobiLink server and to configure MobiLink applications. See Required permissions.
The RDBMS user that the MobiLink server uses to connect to the consolidated database must be able to use the MobiLink system tables, procedures, and so on, without any qualifiers (for example, SELECT * from ml_user).
The RDBMS user must also have SELECT permission on GV$TRANSACTION and V$SESSION, and EXECUTE permission on DBMS_UTILITY. You cannot grant permission directly for the GV$TRANSACTION and V$SESSION synonyms; you must instead grant permission on the underlying GV_$TRANSACTION and V_$SESSION dynamic performance views. You must connect as SYS to grant this access. The Oracle syntax for granting this access is:
grant select on SYS.GV_$TRANSACTION to user-name; |
grant select on SYS.V_$SESSION to user-name; |
grant execute on SYS.DBMS_UTILITY to user-name; |
To set up Oracle to work as a MobiLink consolidated database, you must run a setup procedure that adds MobiLink system tables, stored procedures, triggers, and views that are required for MobiLink synchronization. There are multiple ways you can do this:
Run the syncora.sql setup script, located in %SQLANY12%\MobiLink\Setup.
Check and update the MobiLink system setup from Sybase Central. See MobiLink system setup.
You must set up an ODBC DSN for your Oracle consolidated database. See:
MobiLink synchronization and timestamp-based downloads with an Oracle Real Application Cluster Rows in the consolidated database running on an Oracle RAC may be missed if the clocks of the Oracle cluster nodes differ by more than the time elapsed between the MobiLink server fetching the next last download timestamp and fetching the rows to be downloaded. This problem is unlikely on a RAC system with synchronized node clocks, but the likelihood increases with larger node clock differences. A workaround is to create either a modify_next_last_download_timestamp or modify_last_download_timestamp script to subtract the maximum node clock difference.
At least since version 10i, Oracle has recommended using Network Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster. NTP typically runs by default on Unix and Linux. With cluster nodes properly configured to use NTP, their clocks should all be within 200 microseconds to 10 milliseconds (depending on the proximity of the NTP server). Since Windows Server 2003, the Windows Time Service implements the NTP version 3 protocol which runs by default. Also, as of version 11gR2, Oracle Clusterware includes the Oracle Cluster Time Synchronization Service (CTSS) to either monitor clock synchronization or, if neither NTP or Windows Time Service is running, to actively maintain clock synchronization. However, CTSS and Windows Time Service are less accurate than NTP.
To avoid missing rows when Oracle RAC node clocks differ by up to one second more than the time between fetching the next_last_download_timestamp and the rows to be downloaded, the MobiLink server subtracts one second from the next_last_download_timestamp fetched from the consolidated database if the following are true:
the Oracle account used by the MobiLink server has execute permission for SYS.DBMS_UTILITY
the consolidated database is an Oracle RAC system
for MobiLink versions 12.0.0 and up, there is no generate_next_last_download_timestamp script
For Oracle RAC node clocks that may differ by greater amounts, you can avoid the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp or modify_last_download_timestamp script to compensate for the maximum node clock difference.
Data type mapping The data types of columns must map correctly between your consolidated and remote database. For details, see Oracle data mapping.
CHAR columns In Oracle, CHAR data types are fixed length and blank-padded to the full length of the string. In MobiLink remote databases (SQL Anywhere or UltraLite), CHAR is the same as VARCHAR: values are not blank-padded to a fixed width. It is strongly recommended that you use VARCHAR in the consolidated database rather than CHAR. If you must use CHAR, the mlsrv12 -b command line option can be used to remove trailing blanks from strings during synchronization. This option is important for string comparisons used to detect conflicts.
See -b mlsrv12 option.
Timestamps The MobiLink server uses gv$transaction to generate a timestamp for the remote database to be used in the next synchronization, so the MobiLink server login ID must have a SELECT permission on gv$transaction. Oracle does not allow you to grant access to gv$transaction directly; you must instead grant SELECT permission on the underlying gv_$transaction view. See Permissions.
Stored procedures If you are using stored procedures to return result sets or accept VARRAY parameters, you must select the Procedure returns results or uses VARRAY parameters option for the iAnywhere Solutions 12 - Oracle ODBC driver. Also, Sybase Central requires procedures to return results in order to use central administration of remote databases, so this option needs to be selected when using central administration.
Session-wide variables You can store session-wide information in variables within Oracle packages. Oracle packages allow variables to be created, modified and destroyed; these variables may last as long as the Oracle package is current.
Autoincrement methods To maintain primary key uniqueness, you can use an Oracle sequence to generate a list of keys similar to that of a SQL Anywhere autoincrement field. The CustDB sample database provides coding examples, which can be found in Samples\MobiLink\CustDB\custora.sql. Unlike autoincrement, however, you must explicitly reference the sequence. SQL Anywhere autoincrement inserts a column value automatically if the column is not referenced in an INSERT statement.
Oracle does not support empty strings In Oracle, an empty string is treated as null. In SQL Anywhere and UltraLite, empty strings have a different meaning from null. Therefore, you should avoid using empty strings in your client databases when you have an Oracle consolidated database.
Discuss this page in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |