Skip to Main Content

Database Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Windows 2003 Standard Edition (Cluster Configuration Storage page)

183703Jun 22 2007 — edited Mar 29 2008
I am trying to install RAC R2 on windows Server 2003 (Standard Edition). I am using FireWire 800 SIIG to connect to Maxtor OneTouch III External HDD.

When installing cluster Services, i do not see the Cluster Storage Devices. When i go to Computer Management, i see all the partitions of the raw device.

One "Cluster Configuration Storage" page, the Available Disks show no partitions.

Oracle installtion documentation says "On the Cluster Configuration Storage page, identify the disks that you want to use for the Oracle Clusterware files and, optionally, Oracle Cluster File System (OCFS) storage. Highlight each of these disks one at a time and click Edit to open the Specify Disk Configuration page where you define the details for the selected disk"

In my case, i do not see any disks. What am i missing?

Any Thoughts. Please advise

Thanks
-Prasad

Message was edited by:
pinjam

Comments

807574
Not with 5.2.

If you upgrade all to 6.1, and use lmtp to move mail from front end to back end, indeed, you will be able to do this.
807574
Hi,

sorry for answering 2 year old thread but...

2 front MTAs, 2 backend store all: Sun Java(tm) System Messaging Server 6.2-6.01 (built Apr 3 2006)

at moment we have a number of e-mails stuck in tcp_lmtpcs on front-end MTAs. (waiting for 7 days before bounced...)

history on queue manager shows a number of
Mon, 04 Dec 2006 02:22:11 +0100 (CET)
Temporary error from LMTP partner: lmtp;422 4.2.0 Delivery failed: Over quota

Thanks in advance

Message was edited by:
gljiva

local.store.overquotastatus set to 1 on store?
807574
I'm sorry, I don't see an actual problem described, here. What you describe is how it's supposed to work.
807574
Hi Jay,

as I can see from documentation setting local.store.overquotastatus to 1 on backend store servers will cause overquoted user mailuserstatus to be set to "overquota" (which will actualy do trick).

Howerver, documentation is unclear about mechanism which restore mailuserstatus to active (automatic when user delete e-mails, cron with quota or we need to script something.). Can you point me to right direction?
807574
Hi,
history on queue manager shows a number of
Mon, 04 Dec 2006 02:22:11 +0100 (CET)
Temporary error from LMTP partner: lmtp;422 4.2.0
Delivery failed: Over quota

local.store.overquotastatus set to 1 on store?
You got it. This setting will result in a user who is overquota having their mailuserstatus: attribute changed to overquota. The email relays will then see this and temporarily (4XX) reject emails as 'overquota' rather then accepting then queuing.

Regards,

Shane.
807574
Hi,
Howerver, documentation is unclear about mechanism
which restore mailuserstatus to active (automatic
when user delete e-mails, cron with quota or we need
to script something.). Can you point me to right
direction?
It is the store which monitors the quota for accounts (hence why it's a local.store setting). When the users quota drops (deletion & expunge of email) the store changes the mailuserstatus back to active as appropriate. There is no need to cron or otherwise.

Please note though that the relays have LDAP caches, so it may take up to 15 minutes (default) for the updated LDAP setting to propagate through. So if a user deletes emails to drop below quota and expects a flood of 'queued' emails to show up, they are going to be disappointed.

Regards,

Shane.
807574
we set local.store.overquotastatus to 1 at backend and it worked (partialy). When mailbox hits quota, mailuserstatus is changed to overquota and front-end mta's start to reject new e-mails (4xx) - all as planed.
After e-mail is deleted (one, few or all) trough pop3, imap4, uwc or commexpress, mailuserstatus stays overqoted so new e-mails are rejected. (default or hosted domain, any user)
Which logs I shold be watching (front mta, uwc or back stored)?

(note service.authcachettl is set to 900, we waited for hours and changed parametar temporary to 0)
Message was edited by:
gljiva
807574
Hi,
we set local.store.overquotastatus to 1 at backend
and it worked (partialy). When mailbox hits quota,
mailuserstatus is changed to overquota and front-end
mta's start to reject new e-mails (4xx) - all as
planed.
Good.
After e-mail is deleted (one, few or all) trough
pop3, imap4, uwc or commexpress, mailuserstatus stays
overqoted so new e-mails are rejected. (default or
hosted domain, any user)
If mailuserstatus: overquota was not changed back to active (make sure this is the case by using ldapsearch against the directory, then I wouldn't expect the front-end to stop temporarily rejecting emails).

The first thing you need to confirm is whether the account is REALLY under-quota after deleting the emails. If you delete an email using an IMAP client (e.g. Mozilla Thunderbird) the quota will not drop until the email is expunged (File->Compact Folders, or exit email client).

Are you able to find an account which has mailuserstatus: overquota AND which is under-quota in ./imquotacheck -u <username>?

Regards,

Shane.
807574
ldapsearch for overquota:
- overquoted user mailuserstatus = overquota (ok)
- underquoted user mailuserstatus = active (ok)
- overquoted than underquoted mailuserstatus = overquota (not ok)

e-mail was expunged during imap tests

yes, there is a 50 users now with empty mailboxes and overquota status (imquotacheck against mailuserstatus)
807574
The system is supposed to check the status when the user logs in, or a message is received. If it's not doing that, you might want to

reconstruct -q

jay
807574
Hi,

Could you please provide the output of the following commands for one of the users who is underquota but with overquota set:

ldapsearch -b <basedn> -D "cn=directory manager" -w <directory manager password> uid=<username> mailuserstatus

imquotacheck -u <username>

Thanks,

Shane.
807574
Hi,

after reconstruct -q

user/mmmm: fixed quota root usage

test user was able to receive mail again (mailuserstatus=active) until overquoted again. Than same thing happen (empty mailboxes overquoted users)

Is it a good idea to cron recontruct -q?
During reconstruct -q we also got a number of these:
[12/Dec/2006:02:47:19 +0100] store01 reconstruct[14600]: General Error: set_overquotastatus: cannot get ldap attributes for user: xxxxxx
807574
also: uwc displays proper quota all time
807574
Hi,
after reconstruct -q

user/mmmm: fixed quota root usage
This can occur overtime. It is usually not a big issue. Does user 'mmmm' reflect one of the 'problem' users? If you run recontruct -q again, do you still get these messages?
test user was able to receive mail again
(mailuserstatus=active) until overquoted again. Than
same thing happen (empty mailboxes overquoted users)
Could you please provide the output for the test user for the commands I mentioned earlier (ldapsearch/imquotacheck).
Is it a good idea to cron recontruct -q?
This shouldn't be necessary. If your quota database keeps getting 'out-of-sync' then this would need to be investigated.
During reconstruct -q we also got a number of these:
[12/Dec/2006:02:47:19 +0100] store01
reconstruct[14600]: General Error:
set_overquotastatus: cannot get ldap attributes for
user: xxxxxx
Did the user in this example exist in the directory or are they 'orphan' accounts?

Can you see an LDAP search (access logs) which correlates to this date stamp which returned an error?

Regards,

Shane.
807574
Hi,

after reconstruct -q and fixed quota root usage only thing that changes is mailuserstatus from overquota to active (quota and other attributes in ldap remain unchanged). When we repeat reconstruct -q, nothing is changed (no quota fix). After that we fill mailbox to top, mailuserstatus goes overquota. Than we emtpy mailbox, but mailuserstatus remains overquota.. Running reconstruct -q fix mailuserstatus. (at all time ldapsearch and quotacheck provide acurate information)

For "cannot get ldap attributes for", all mailbox in question were orphans (all ldap errors were related to orphans, we removed orphans and error is gone).

Here is step-by-step test for testuser "gljiva"

1) mailbox emtpy
ldapsearch (short version, full version is very long - includes portal attributes):

version: 1
dn: uid=gljiva,ou=People,o=xxxx,dc=xxx,dc=xxx
mailUserStatus: active
mailDeliveryOption: mailbox
mailQuota: 41943040
uid: gljiva
inetUserStatus: Active

imquotacheck:
User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
gljiva 40960 54 0 - 3 - - -

2) mailbox is filled to top
ldapsearch (short version):
version: 1
dn: uid=gljiva,ou=People,o=xxxx,dc=xxx,dc=xxx
mailUserStatus: overquota
mailDeliveryOption: mailbox
mailQuota: 41943040
uid: gljiva
inetUserStatus: Active

imquotacheck:
User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
gljiva 40960 44850 100 - 7 - 12/12/06 -

3) mailbox is cleaned (pop3 download)
ldapsearch:
version: 1
dn: uid=gljiva,ou=People,o=xxxx,dc=xxx,dc=xxx
mailUserStatus: overquota
mailDeliveryOption: mailbox
mailQuota: 41943040
uid: gljiva
inetUserStatus: Active

ldapsearch after 30 min. (or more):
version: 1
dn: uid=gljiva,ou=People,o=xxxx,dc=xxx,dc=xxx
mailUserStatus: overquota
mailDeliveryOption: mailbox
mailQuota: 41943040
uid: gljiva
inetUserStatus: Active

imquotacheck:
User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
gljiva 40960 54 0 - 3 - - -

4) after reconstruct -q (user/gljiva: fixed quota root usage) ONLY (diff) changed ldap attribute is mailuserstatus

ldapsearch:
version: 1
dn: uid=gljiva,ou=People,o=xxxx,dc=xxx,dc=xxx
mailUserStatus: active
mailDeliveryOption: mailbox
mailQuota: 41943040
uid: gljiva
inetUserStatus: Active

imquotacheck:
User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
gljiva 40960 54 0 - 3 - - -

Same thing ocur if e-mail's are deleted trough uwc, pop3 or imap4(+purge).

Curent patch level of messaging components are:
118207-38 backend store
118207-51 frontend mta's
118207-38 frontend uwc
807574
Hi,

I was unable to reproduce what you saw with my own test system (patch release 118207-60).

**Set account to be overquota**

User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
user003 512 512 100 - 810 - 12/13/06 -

**Account marked in ldap as overquota**

bash-2.05# ldapsearch -D "cn=directory manager" -w password -b "o=domain1.com,o=isp" uid=user003 mailquota mailuserstatus
uid=user003, ou=People, o=domain1.com, o=isp
mailquota=524288
mailuserstatus=overquota

**deleted and expunged/compacted folders using IMAP**

bash-2.05# ./imquotacheck -u user003
User Name Quota(K) Usage(K) % Quota# Usage# % OverDate WarnDate
-------------------- -------- -------- --- ------- ------- --- -------- --------
user003 512 225 43 - 384 - - -

**Account no-longer marked in ldap as overquota **

bash-2.05# ldapsearch -D "cn=directory manager" -w password -b "o=domain1.com,o=isp" uid=user003 mailquota mailuserstatus
uid=user003, ou=People, o=domain1.com, o=isp
mailquota=524288
mailuserstatus=active

So you may want to try a newer patch release on the backend stores (e.g 118207-58 which is the latest publically available patch). You should be able to verify this in you own test environment before pushing into production.

Regards,

Shane.
807574
Hi,

I reviewed bug fixes in 118207-58, and there are some issues related to overquota. But, no bug similar to this one. I would like to debug this (stored on backend?) before patching...

Message was edited by:
gljiva
1 - 17
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Apr 26 2008
Added on Jun 22 2007
3 comments
2,896 views