The team from Linux Mint released a new point-release of their 18.x version at the end of November.
Atlas runs on it unchanged since its 18.2 incarnation to make getting Oracle 12c (release 1 or 2) running on it simply:
The team from Linux Mint released a new point-release of their 18.x version at the end of November.
Atlas runs on it unchanged since its 18.2 incarnation to make getting Oracle 12c (release 1 or 2) running on it simply:
Just as I get Atlas working on Fedora 26, so they go and release a brand new version of it: version 27 was released on November 14th.
There is a ghastly new look (I suggest changing the default jellyfish wallpaper the moment you first log on!), but there is otherwise not a lot listed as being new in the release notes, apart from an upgrade to the latest release of LibreOffice.
Mostly underwhelming, in other words; but still just about the most functional distro out there (imho, naturally). It remains my desktop of choice, anyway. Unfortunately, I can’t actually upgrade my main desktop to version 27 because when I do, I get told:
Error: Problem: package zfs-dkms-0.7.3-1.fc26.noarch requires /bin/ksh, but none of the providers can be installed - ksh-20120801-35.fc26.x86_64 does not belong to a distupgrade repository - problem with installed package zfs-dkms-0.7.3-1.fc26.noarch
As far as I have been able to tell, this is caused by the ZFS on Linux project not having Fedora 27-compatible repositories ready -and, allegedly, they won’t have one until mid-December. So any Fedora 26 users who have committed to using ZFS for their important data won’t be able to upgrade for a few weeks. Fingers crossed for the December timeline.
My laptop doesn’t use ZFS, though, and was able to upgrade without drama.
I’ve also re-jigged Atlas, so Oracle 12c will run on Fedora 27 without too much fuss (the same need to do a software-only install that plagued version 26 also affects version 27, but the workaround previously described works for the new version of Fedora perfectly well):
The future does not look especially great for Solaris, given Oracle Corporation’s seeming reluctance to hold on to its principle sources of Solaris development expertise.
However, OpenIndiana (which is based on the forked, open source Solaris 10) continues to be fitfully developed and refreshed by its loyal band of devotee developers: a brand new release hit the download servers at the tail-end of October (and is thus called the 1710 release of the Hipster fast development branch of OpenIndiana).
It is probably slightly odd to spend any time worrying about whether Oracle 12c runs on this new version of OpenIndiana, given its niche appeal and the imminent demise of the ‘real thing’ it’s based on. But I did anyway… and I can therefore report that both 12cR1 and 12cR2 install without drama.
12c Release 2 complains of a missing package, called ‘assembler-0.5’, but this warning can be ignored and the installation will continue to a successful conclusion anyway. There are no warnings about anything with 12c Release 1, I’m happy to say.
To make things easier, I’ve re-jigged Atlas to work to get these installations automated. Atlas was always promised to be the ‘universal’ script to get Oracle installed on ‘*nix’, so getting it to work for ‘proper’ Unix as well as for Linux is, if anything, long overdue.
I’ll be updating the Atlas documentation to reflect its new-found OpenIndiana-capabilities in the course of the next day or so. In the meantime, the short version is simply to build a Hipster VM with at least 5120MB of virtual RAM, then:
wget https://bit.do/dizatlas -O atlas.sh chmod +x atlas.sh ./atlas.sh
After that, follow the prompts to completion (including a reboot). Then download the Solaris X86 flavour of one of the Oracle 12c database versions, unzip the download(s) and then invoke the Oracle installer by the usual database/runInstaller command.
Way back on July 11th, I welcomed the release of Fedora 26 and noted that Atlas didn’t run on it properly: the Oracle software would link properly, but no executables could then be run. I promised to look into it and see what I could do to come up with a fix.
Unfortunately, I reckoned without the fact that my barely-functional study swiftly thereafter got dismantled by the builders who proceeded to put down a new floor, ruin it, replace it, ruin that and finally installed a third that they managed not to screw around with! Long story short, I’ve been without functioning computers for many weeks and it’s only in the past couple of days that I’ve been able to turn my attention to the Oracle/Atlas/Fedora conundrum. (Which is a bit sad, as Fedora 27 is due to be released imminently! But better late than never, I guess…)
Anyway, it turns out that the problem concerns the new version of glibc that ships with Fedora 26. It interacts with the Oracle compiler in ways that prevent all binaries produced by the linking phase from being able to run correctly (or, indeed, at all).
I had hoped that by now, an updated version of glibc might be shipping that would have meant the linking phase could produce functional binaries, but no such luck. Therefore, I am reduced to having to re-compile all the binaries after a software-only Oracle installation and having first made sure that Oracle’s own versions of libc-related libraries are deleted.
The short story is, therefore, that a new version of Atlas has been released (1.6, if anyone’s counting) that works to allow a software-only install of Oracle 12R1 or 12R2. Fedora 26 users can thereafter run the ~/Documents/atlas-postinstall.sh script to trigger the correct re-linking of all the Oracle binaries and the automated creation of a database (for which the SYS and SYSTEM passwords are set to “oracle”). It isn’t pretty and I wish there were a nicer way of achieving it, but it at least works:
I have updated the Atlas/Fedora-specific documentation shortly to take account of this new way of having to do things.
On July 2nd, it was the turn of Linux Mint to release a new version, code-named Sonya, numbered 18.2.
It’s based on Ubuntu 16.04, which means it suffers from the usual problems that beset any Ubuntu-based distro when trying to install Oracle 12c Release 2… basically, nothing works at all! However, installing and using 12c Release 1 is fine.
Nothing about Atlas therefore has changed: it can be used as-is to achieve simpler 12cR1 installs on the new distro version:
Incidentally, I am still trying to work out what is going wrong with Ubuntu (and Ubuntu-based!) distros and 12c Release 2. I am not having much luck tracking it down, though. If anyone has input they’d care to offer, I’m all ears!
There are lots of changes under the hood, but few that make a major difference to the desktop experience (unless you count the death of ‘Ice Weasle’ and the return of vanilla ‘Firefox’ major).
Unfortunately, as I mentioned way back in January, the Atlas-assisted Oracle installation fails completely when run on the finished Debian 9 because of problems with the latest version of gcc and g++, resulting in an ‘error in invoking target links proc gen_pcscfg procob’ failure as soon as the linking phase starts.
Happily, it’s fixable by forcing the use of an older version of the gcc compiler, using the commands (run as root, before attempting the Oracle installation at all):
apt-get install gcc-4.9 g++-4.9 update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.9 50 update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 50 update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.9 50 update-alternatives --set g++ /usr/bin/g++-4.9 update-alternatives --set gcc /usr/bin/gcc-4.9 update-alternatives --set cpp-bin /usr/bin/cpp-4.9
When you are about to launch the database/runInstaller, check that your environment has picked up the ‘old’ compiler version by typing gcc -v… you should see a great pile of techie stuff, ending in the lines:
Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10)
If your oracle user sees something like that, then the Oracle installation will succeed:
The problem affects 12cR2 just as much as 12cR1. Fortunately, the same fix applies equally well to both Oracle versions, too:
I haven’t ported this fix into Atlas as yet: it’s something you have to do manually at the moment, but when time permits, I’ll automate this as I automate everything else!
Atlas now includes the fix for Debian 9 and therefore now correctly automates 12cR1 and 12cR2 installations on that distro without error.
Continuing the saga of “catching up” with software developments whilst I was en route to the UK from Australia, the question next to be addressed is simply: does Atlas work to allow Oracle 12c Release 2 to be installed onto the many and various distros it claims to support.
The answer is a bit mixed, I’m afraid!
First thing to say: I deliberately coded Atlas to specifically declare 12cR2 ‘didn’t work yet’ when I first released it. So, for it to work for 12cR2 at all, that bit of code has to be removed -and that means Atlas straightaway gets bumped to version 1.2.
Once that code has gone, the good news is that Atlas will successfully help 12cR2 be installed on the majority of the distros it works with (15 out of 19, as it happens). But the bad news is that if your distro is Ubuntu or even just Ubuntu-based, then the linking phase of the Oracle 12c Release 2 installation fails irreparably after Atlas has been run.
The complete list of distros and their results with Atlas for 12c Release 2 is therefore as follows:
Debian 8.2+ ............................ Works fine Linux Mint 18+ ......................... Fails Mint Debian Edition 2+ ................. Works fine Red Hat ES 7.0+ ........................ Works fine Scientific Linux 7.0+ .................. Works fine CentOS 7.0+ ............................ Works fine OpenSuse Leap 42+ ...................... Works fine Antergos 2016.11+ ..................... Works fine elementary OS 0.4+ ..................... Fails Mageia 5+ .............................. Works fine Korora 25+ ............................. Works fine Zorin Core 12 .......................... Fails Ubuntu 16+ ............................. Fails Manjaro 15+ ............................ Works fine Fedora 23+ ............................. Works fine Peppermint Linux 7+ .................... Fails GeckoLinux Static 422+ ................. Works fine Chapeau Linux 24+ ...................... Works fine PCLinuxOS 2016+ ........................ Works fine
As I say, the pattern is pretty obvious and I suspect the problem is that the gcc versioning tricks I had to pull to get 12cR1 to compile properly on any Ubuntu-based distro back in January are now the cause of woes for 12cR2. The failure always manifests itself in the following manner:
There’s no recovering from that as yet, but I hope to get it sorted within the week.
On the other hand, for any distro listed as working fine in the above list, you can expect the usual plain sailing:
That’s specifically Oracle 188.8.131.52 running on GeckoLinux, which is a spin of openSUSE Tumbleweed, but you get the same outcome for all non-Ubuntu distros.
Whilst testing all this, I discovered a couple of distros which had incremented their version strings since January (Manjaro, for instance, now reports itself as version ’17.something’, so the part of Atlas where it checked for version strings containing the numbers 15 or 16 obviously needed updating). Those sorts of versioning updates are now also included in Atlas 1.2.
There is very little updating of the Atlas doco to do, happily. For a start, you will obtain the new Atlas version just by running exactly the same wget command as was previously documented: the URL alias simply points to the latest version, but the URL itself doesn’t change.
When you install Oracle 12cR2 onto any of these non-standard distros (except the RHCSL ones, of course), you will get this dire-looking warning:
It’s better than the 12cR1 equivalent, which was to say ‘your system is inadequate’! Anyway, for all the distros for which Atlas works at all, it’s perfectly OK to say ‘yes, I want to continue’. The installation will succeed anyway.
Have fun… and wish me luck whilst battling with Ubuntu later this week 🙂
Let me start by wishing a happy New Year to all my readers, complete with fireworks from our local council’s display!
And then let’s swiftly move on to the bad news!
If you are interested in installing Oracle onto non-approved Linux distros, you are very soon going to have to contend with this sort of error message:
/usr/bin/ld: /u01/app/oracle/product/12.1.0/db_1/lib//libpls12.a(pci.o): relocation R_X86_64_32 against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC
This will be found in the Oracle installer’s log immediately after the “linking phase” of the Oracle installation starts.
Unfortunately, the error message dialog that appears at this point looks like this:
…and that particular error message has long been familiar from 184.108.40.206 installs on assorted distros. The workarounds then were to add various compilation flags to assorted makefiles.
But in this case, the graphical error dialog deceives: for a start, this is happening on 220.127.116.11, and although the dialog text is the same as back in the 18.104.22.168 days, the underlying cause is completely different. It’s only when you inspect the installActions log do you (eventually!) see the error text I showed above, which tells you that this is no “ordinary” compilation problem.
Welcome to the world of position-independent code.
Putting it as simply as I know how, the basic idea of position-independent code is that it allows execution of code regardless of its absolute memory address. It’s thus a ‘good thing’, on the whole.
Trouble is, if objects within the code you’re trying to compile haven’t themselves been compiled to be position-independent, then you aren’t yourself allowed to compile the code that references them into shared libraries.
As the error message above says, since “pci.o” isn’t position-independent, you can’t compile references to it into the libpls12 library. Note that the error message does not mean that your attempt to compile libpls12 should use fPIC: if it meant that, you could do something about it. No: it’s telling you that pci.o was compiled by Oracle without fPIC. Only if they re-compile that object with the fPIC compiler option switched on would you then be able to compile it into the libpls12 library successfully.
If you’re best mates with Larry, then, perhaps you’ll be able to get him to do the necessary recompilations for you! Mere mortals, however, are stuck with the unhappy fact that vast swathes of the Oracle 12c code-base has not been compiled to be position-independent… and there’s nothing you can do to fix that when your version of gcc insists that it should be.
The problem doesn’t manifest itself on all distros: Ubuntu 16.04, for example, has no problem installing 12c at all (apart from the usual ones associated with not using a supported distro, of course!) But Ubuntu 16.10 does have this fatal problem. Similarly, Debian 8 is fine with Oracle 12c, but Debian 9 (the testing branch, so not yet ready for mainstream release) fails. And whereas Manjaro didn’t have a problem earlier in the year when I first released my mercury pre-installer script, it does now.
This, of course, gives us a clue: there’s clearly some component of these distros which is being upgraded over time so that later releases fail where earlier ones didn’t. So what’s the upgraded component causing all the trouble?
Perhaps unsurprisingly, given that it’s a compilation error that shows you there’s a problem in the first place, it turns out that the gcc compiler is the culprit.
If you do a fresh install of Ubuntu 16.04 (the long-term support version, so still very much current and relevant), whilst making sure NOT to update anything as part of the installation process itself, issuing the command gcc -v will show you that version 5.4.0 is in use. Do the same thing on Ubuntu 16.10, however, and you’ll discover you’re now using gcc version 6.2.0.
A fresh Debian 8.6 install, subjected to an apt-get install gcc command, ends up running gcc version 4.9.2. The same thing done to a fresh Debian 9 install results in a gcc version of 6.2.1.
Manjaro is a rolling release, of course, so it’s software components are forever being incrementally upgraded: it makes finding out what gcc version was in use at the start of the year rather tricky! So I don’t have hard evidence for the gcc version shift there -but my main desktop is currently reporting version 6.2.1, so I’ll stick my neck out and say that I would lay odds that, had I checked back in January 2016, I think I would have found it to be around version 5.something.
In short, for all three distros currently under my microscope, a shift from gcc 4- or 5-something to 6-something has taken place… and broken Oracle’s installation routine in the process.
It means that all distros will eventually come across this compilation problem as they eventually upgrade their gcc versions. Expect Fedora to keel over in short order, for example, when their version 26 is released next April (assuming they go for a late-release version of gcc 6.something, which I expect they will). No doubt we’ll have all moved on to installing Oracle 12c Release 2 by then, which is probably suitably position-independent throughout… so maybe no-one will ever have to worry about this issue again. But in the meantime… the constantly changing nature of gcc is a problem.
So, what’s to be done if you want Oracle 12c installed on these distros with their fancy new gcc versions? Nothing I could really think of, except to ensure that the old, functional versions of gcc and related development tools are installed …and that can be easier said than done!
On Debian 9 (‘testing’), for example, instead of just saying apt-get install gcc, you need to now say apt-get install gcc-5, which ensures the ‘right’ compiler version is installed, with which the Oracle installer can live. Thus can this screenshot be taken:
…which shows me happily querying the EMP table on 22.214.171.124 whilst demonstrating that I’m running Debian Testing (codenamed “Stretch”). That’s only possible by careful curating of your development tool versions.
The same sort of ‘install old gcc version and make it the default’ trick is required to get 12c running on Ubuntu 16.10 too:
-though I had to specifically install gcc-4.9 rather than “gcc-5”, since the compilation error still arose when ‘gcc-5’ was installed. These things get tricky!
Anyway: there it is. Gcc’s constant version increments create havoc with Oracle 12c installations. Coming to a distro near you, soonish!
I was a bit busy this week, what with having my second cataract removed and all… so I missed the release of a new version of openSUSE on 16th November.
However, I’ve caught up now and as the thumbnail to the left attests, my quatro script works on the new release just fine to facilitate easy Oracle Enterprise Edition installations.
See the Quatro main page for screen-shotted walk-through details of how to perform the installation.
No version of SQL Server supports replicating to Oracle 12c out of the box.
This took us a little by surprise at work, since things had been replicating just fine in our equally-12c test environment. The difference in Production that arose this week, however, was that somebody decided to re-initialise the SQL Server publish-and-subscribe replication in that environment. This caused SQL Server to drop the replication-controlling table from Oracle and to re-create it from scratch -and only at that point does the lack of 12c support reveal itself.
The symptoms are easy to describe: if you check your replication monitor in the SQL Server Management Studio, you’ll see this error (or variations on it):
The cause of this is also quite easily found. In the SQL Server msdb database (under Programmability > Stored Procedures > System Stored Procedures, if you’re browsing in the Management Studio), you’ll find a procedure called sys.sp_MSrepl_createdatatypemappings. It contains this code snippet:
IF OBJECT_ID(N'dbo.MSdbms_datatype', 'U') IS NULL BEGIN print 'Creating table MSdbms_datatype' create table MSdbms_datatype ( datatype_id int NOT NULL IDENTITY, dbms_id int NOT NULL, type sysname NOT NULL, createparams int NOT NULL DEFAULT 0, CONSTRAINT pk_MSdbms_datatype PRIMARY KEY (datatype_id), CONSTRAINT fk_MSdbms_datatype_dbms_id FOREIGN KEY (dbms_id) REFERENCES MSdbms (dbms_id) ) exec dbo.sp_MS_marksystemobject 'MSdbms_datatype' -- -- Define default dbms data types -- exec sys.sp_MSrepl_MSSQLdatatypes 'MSSQLServer' exec sys.sp_MSrepl_DB2datatypes 'DB2' exec sys.sp_MSrepl_ORAdatatypes 'Oracle' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '8' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '9' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '10' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '11' exec sys.sp_MSrepl_SASdatatypes 'SYBASE' END
You’ll note that it’s creating a table to govern the ‘data type mappings’ between SQL Server and various other databases -in other words, and as an example, where SQL Server says ‘INT’ or ‘BIGINT’, Oracle will say ‘NUMBER’. SQL Server needs to be able to translate its data types to those used by ‘foreign’ databases, and this code sets that translation mechanism up.
Unfortuately, you’ll also note that whilst the code goes on to populate this data mapping table with translation entries for Oracle versions 8, 9, 10 and 11… there’s nothing at all for Oracle 12! It’s this lack of a description as to which SQL Server data types should become which Oracle 12c ones that explains replication’s inability to create its MSREPL7 table correctly.
If, despite receiving that earlier error when first attempting to create a new subscription to an Oracle database, you describe the MSREPL7 table that will actually have been created in Oracle, you’ll see this sort of thing:
Notice all those “INTERVAL DAY(2) TO SECOND(6)” columns? They’re actually supposed to be NUMBER(10) and NUMBER(3) columns. Those BINARY FILE LOB columns are all supposed to be RAW(16), too.
MSREPL7 is the ‘governor’ for SQL Server replication: it records what tables are supposed to be replicating and what transaction they’re up to in the destination (Oracle) database. When the SQL Server source database next wants to send transactions to Oracle, it’s this table which tells it which transactions have already been sent and which have not. So when this ‘governor’ table is screwed up, you won’t get very far with any replication!
As an aside, things are slightly more complicated if you upgrade to 12c from a previously-working 11g. In that case, you’d already have had replication working nicely, even after completing the 12c upgrade process, and thus the MSREPL7 table would have all the right data types and there’d be no impediment to replication continuing to work. The other tables you’re replicating will also already exist in your newly-upgraded 12c database and they’ll have all the right columns too. So they will replicate nicely as well. So, you will think that all is well… because it is!
It’s only when someone decides to reinitialize replication that it will all go pear-shaped, because it’s only at that point that SQL Server will drop the tables being replicated and attempt to re-create them… with all the wrong data types! When you then attempt to push a number from SQL Server into a column in Oracle that’s been freshly-created as an INTERVAL data type, that’s when sparks will fly.
This is why we didn’t realise that upgrading to 12c would be an issue in our various test environments: no-one had attempted to re-initialize the replication; and with many multi-hundred-million rows to be pushed across into Oracle, it was a fair bet that no-one would be daft enough to do that in Production either! Unfortunately, it turned out that my gambling instincts were wrong on this occasion: someone was daft enough to hit the wrong menu options, and thus the trouble began.
I couldn’t find much about this problem on Google, which was rather surprising (if one major database has trouble replicating to another major database, I would have expected to hear a lot about it by now!)
I did find enough to make me look at the column types in MSREPL7, and notice that all sorts of odd data types were in use. That got me hunting down any references to how SQL Server knows what data type maps to what in Oracle. And finally, that got me to the stored procedure the code from which appears above.
Looking at that code, it’s just begging for an extra line to be added to it, no?! I mean, if it read:
exec sys.sp_MSrepl_ORAdatatypes 'Oracle' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '8' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '9' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '10' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '11' exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '12'
…then maybe all the troubles would go away, right?
But you can’t just run that sort of thing in the standard SQL Server Management Studio. For this, you need to run it in DAC (or ‘dedicated administrative connection’) mode. To do that, fire up SSMS as normal and connect to your SQL Server instance as normal. Click New Query to start a new query window. Finally, click the ‘change connection’ button, just to the left of the database selector:
That will pop-up a new dialog box to allow you to make a fresh connection to your SQL Server instance:
But notice this time that I’ve stuck ADMIN: in front of my usual ‘server name’ connection string. That will connect you in the right ‘god mode’. You can’t really tell anything is different from a non-DAC connection, apart from the ‘admin:’ identifiers scattered all round the SSMS interface if you look in all the right places!
Anyway, once you’ve got a DAC connection, you can type in this lot of SQL and run it:
USE master GO exec sys.sp_MSrepl_ORAdatatypes 'Oracle', '12' GO exec sys.sp_MSrepl_MSSQL_ORA_datatypemappings @source_dbms = N'MSSQLSERVER', @destination_dbms = N'ORACLE', @destination_version = '12' GO
If all goes according to plan, you should see this sort of response:
Once the data types have been created for Oracle 12, drop the MSREPL7 table from your Oracle database and then try re-initializing your replication subscription once again. This time, it should just work:
That shows you me dropping MSREPL7 in a SQL*Plus window in blue; then I went and re-initialized the replication in SQL Server (which you can’t see me doing). You then see me describing the structure of MSREPL7 in the blue window: notice (a) the table has been re-created despite just being dropped; and (b) it’s been created with NUMBER and RAW data types for its columns, not INTERVALS and BLOBs. The Synchronization Status progress window finally shows that replication transactions were successfully delivered to the Oracle database.
You can also issue the required fixup SQL in the command-line sqlcmd tool. Connect to your database in DAC mode with the “-A” switch:
sqlcmd -S winsql\winsqldb -E -A
The -S takes the form it does here because it describes the server AND the instance to connect to (I use named instances). Hence “winsql” is the server name and “winsqldb” is the instance to connect to running on that server. The -E switch means “use Windows authentication”, because that’s what I do! If you use named users, you’d use the -U switch and specify the username (and the -P switch if you fancied typing his password in clear text on the command line!). The -A switch means, as I’ve mentioned, connect in DAC mode.
Note that DAC mode is only available locally: that is, you have to be working on the actual server that’s hosting the SQL Server instance. If you insist on running the fixup SQL remotely, you can enable remote DAC access by right-clicking the instance in SSMS, clicking Facets, selecting Surface Area Configuration from the drop-down menu and then setting RemoteDacEnabled to True. You also need the SQL Browser service to be running (which you can switch on from the normal services utility, or by running the SQL Server Configuration Manager, clicking the SQL Server Services item and then the SQL Browser item in the right-hand pane (right-click it and click Start).
Incidentally: you may have thought (as I innocently did) that upgrading your SQL Server from (say) 2008 R2 to (say) 2016 would help. All I can tell you is that the code snippet which appears at the top of this piece is as identically 12c-deficient in SQL Server 2016 as it is in any previous version. I found this surprising and completely inexplicable: I’m prepared to forgive SQL Server vintage 2008 for not knowing about Oracle 12c; I find it much harder to understand why SQL Server 2016 is silent on the subject!
So, as far as I know, this trick of manually adding a reference to 12c in DAC mode is the only way to get any version of SQL Server replicating to Oracle at all.
Whether bolting on a ’12’ to the end of a bit of code and running it is actually supported by Microsoft, I can’t say: I’ve looked for any indication it’s a properly-supported technique in all the usual places and turned up nothing either way.
But if you’re replicating SQL Server to Oracle 11g and thinking of upgrading to 12c any time soon, it might be useful to bear in mind that you’re going to need this technique should you ever need to re-initialize your subscriptions 🙂