ERR_TOO_MANY_REDIRECTS in Apex login for http and not for https

I have had this mysterious error before and I never knew where it came from or how to solve it. Sometimes it was there, sometimes not. And I was very scared, because if you don’t know where it comes from and suddenly it occurs in production, what then…?

Now I spent a lot of time in investigating this, and I think I found the explanation.

I was setting up a new apex environment and the behaviour was that accessing the login page via https is ok, while accessing it via http gives the error ERR_TOO_MANY_REDIRECTS.

Real ODA “one button patching”, 12.1.2.6 to 12.1.2.10

Today I had to patch a virtualized Oracle Database Appliance X5-2 HA at a customer site. Current version was 12.1.2.6, installed in June 2016, and it had to be upgraded to 12.1.2.10. I’ve heard a lot of scary stories of colleagues and friends about possible issues during patching, so I was a little reluctant to do this. Anyway, no choice, what needs to be done, needs to be done.

I had one big advantage: this ODA was installed by myself and I was 100% sure that nobody had ever done something ‘unsupported’ with it. During installation in June 2016, I have taken very much care about following the books accurately and ensuring that nothing went wrong. This was a real clean install without any issues, now in production for 1 year.

Now one year later I have to say that I am very happy with “my ODA”. The patching today went smoothly. Not a single issue was encountered during the patching. Actually I was a little surprised, because as I said, I have heard about many issues of others during patching.

Why DB_BIG_TABLE_CACHE_PERCENT_TARGET was a good solution in my case

During the preparation of my Oracle DBA 12c Certified Master exam, I learnt about the DB_BIG_TABLE_CACHE_PERCENT_TARGET parameter in 12c. This parameter allows you to reserve a certain percentage of the buffer cache for storing large tables. You know that full table scans on large tables are normally NOT stored in the buffer cache (they also use direct reads, bypassing the buffer cache), because it should not be the intention to keep scanning large tables over and over again.

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Conclusion

This is a follow-up of chapter 5.
The most important thing in this story is the fact that it is perfectly possible to configure your Oracle RAC cluster with 2 storage boxes in a safe way. You just need an independent location for the 3rd voting disk, but if you have that, you can be sure that your cluster will remain running when one of those storage boxes fail. You will even be able to repair it without downtime after e.g. buying a new storage box (call Uptime for good prices…:)

So were all these tests then really needed? Yes, I do think so, because of the following reasons

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Chapter 5

Scenario 5: Loss of ocrmirror from non-ocr-master – reloaded

This is a follow-up of chapter 4.
In this final scenario, we do the same thing as in scenario 4. I.e. while crs is running on both nodes, we hide the ocrmirror from the non-ocr-master node, which is node 2 now.
So node 1 is the master, we hide ocrmirror from node 2 and we verify on node 2:

(nodeb01 /app/oracle/crs/log/nodeb01) $ dd if=/dev/oracle/ocrmirror of=/dev/null bs=64k count=1
dd: /dev/oracle/ocrmirror: open: I/O error

What happens?

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Chapter 4

Scenario 4: Loss of ocrmirror from the non-OCR MASTER

This is a vollow-up of chapter 3.
Let’s try to do the same thing as scenario 3, however now hiding the lun from a node NOT being the OCR MASTER, while crs is running on both nodes.

What happens?

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Chapter 3

Scenario 3: Loss of OCRmirror from the OCR MASTER only

This is a followup of chapter 2.

As we have seen in scenario 1, the OCR MASTER will update the votecount. Now let’s hide the ocrmirror from only 1 node: the node being the OCR MASTER, while the other node continues to see the ocrmirror. Will CRS get confused about this?

Note: while doing this test, crs is running on both nodes.

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Chapter 2

Scenario 2: loss of ocrmirror, both nodes down

(This is the follow-up of chapter 1)

Let’s investigate the vote count a little further by doing the following test:

• First stop crs on both nodes
• Then make the lun with ocrmirror unavailable to both nodes

What happens?

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Chapter 1

Scenario 1: loss of ocrmirror, both nodes up

(This is the followup of article “Introduction“)

Facts

• CRS is running on all nodes
• The storage box containing the OCRmirror is made unavailable to both hosts (simulating a crash of one storage box).

What happens?

The ultimate story about OCR, OCRMIRROR and 2 storage boxes – Introduction

Some time ago I wrote a blog about stretched clusters and the OCR. The final conclusion at that time was that there was no easy way to get your OCR safe on both storages, and hence I disrecommended clusters with 2 storage boxes. However, after some more investigation I may have to change my mind. I did extended testing on the OCR and in this blog I want to share my experiences.