In my case when I login to Juniper SSL web interface it run host-checker and as Linux is not supported the web form does not have way to launch Junos Pulse SSL VPN client. In fact that client does not exists for Linux.
Good news are: old Juniper “Network Connect” client is compatible with Junos Pulse and can be used on Linux client.

Both are py scripts to simulate browser behaviour. Great stuff, But it did not work for me. I believe its because before I can get to login page I have one more “Legal” page where “Agree” has to be clicked. So I decided to actually use browser for login, and just have an automated way to pass DSID cookie to the script to launch ncui. Below are steps for that. –

Get DSID cookie in persistent form, and Plug it to ncui.
Problem with DSID cookie – its Session Level, so it does not persist on disk, where you can grep it from. So had to use Greasemonkey plugin for firefox to capture DSID and save to HTML5 storage.
Install Greasemonkey plugin https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ and make sure its enabled.

No need to even RESETLOGS if redo logs are still available, so – ZERO data loss!

Some rman metadata could be lost, but most of it could be registered back by:

RMAN> CATALOG START WITH '/directory/where/backups/are/'

Same thing for registering back archive logs:

RMAN> CATALOG START WITH '/directory/where/archlogs/are'

Used it couple times, worked as a charm.

The only restrictions: all files mentioned “create control file” statement has to exists, as oracle probe their headers to get SCN and other metadata. If that is not met, better bet on restore of control file from binary backup.

If you see “ORA-01555: snapshot too old” from Select what is been run on Physical standby, but same select runs on primary just fine, and all relevant init.ora parameters and undo tablespace are exactly identical between primary and standby,- its odd. But its easy to explain.

First check if DB is below 11.2.0.3 DB it could be bug 10320455.

If not – it most probably just undo retention problem.

On Primary instance Increase undo_retention to value (in seconds) higher than time query runs, and it should fix the problem. (You can increase the parameter on standby too, but it really take effect on primary only)

Why with same undo_retention problem does not show up on primary?

There is underscore parameter _undo_autotune. With it been set to TRUE (default in 11g) Oracle would track oldest running query, and will try to keep undo from time of start of that oldest query, even if its older than undo_retention. If undo space affords. So it basically overwrites undo_retention and can be much higher than undo_retention. The overwritten/actual undo retention can be seen in tuned_undoretention column in v$undostat.

But primary DB have no vision on what queries are running on standby, so even if long running query running on standby – undo autotune does not kick in, and real undo retention on primay (and so standby) equal to what is set in undo_retention parameter.

So setting undo_retention on Primary to higher value would fix the problem. And note it had to be set on primary. For standby DB undo tablespace is Read-Only so it has no control on it.

Setting undo_retention higher should not hurt much. It can grow your tablespace to what autoextend allows, but if it hits the limit and more undo been generated what is really needed by uncommitted transactions, it will purge old undo what is only needed by selects. It is soft limit.

If VIP was failed over from one host in subnet to another via manually running “ifconfig down” on one host and “ifconfig up” on another, you can see case when VIP become unreachable from outside of subnet. the problem should clear. but it can take up to several hours, depending on the platform.
If you have similar symptoms run on machines where VIP failed over to:

[root@linuxtest ~]# arping -U your_vip_ip

It will send ARP response, Gratuitous ARP, aka Unsolicited ARP. What would broadcast new MAC for the VIP and so update ARP caches on machines in same subnet, including router what routes traffic to the subnet from external world.
If not done, ARP caches will be updated but it would take time:
– for some cisco devices – 4 hours,
– for brocade – default is 10 minutes,
– for Linux – default is 60 seconds,
– for Windows – up to 10 minutes.

So cleaning arp cache would help for new connections to avoid waiting for arp timeout.
Also it will help for clients which had existing TCP connection before failover: they will immediately get a reset packet sent. This results in clients getting errors immediately rather than waiting for the TCP timeout (up to 15 minutes, depending on platform).