how to uninstall symantec Endpoint Protection from windows 7 laptop

I am having issues uninstalling Symantec Endpoint Protection Client. Each time I tried to uninstall it, it just rolled back.
Finally Here is what helped me: youhave to uncheck Protect Symantec security software from being tampered with or shutdown: After this, go to control panel->programs and features and click symantec to uninstall. then restart.

To allow Symantec Endpoint Protection services to be configured

1. Right-click the Symantec Endpoint Protection icon in the lower right corner of the screen, and click Open Symantec Endpoint Protection.
2. In the left pane, click Change Settings.
3. In the right pane, click Client Management > Configure Settings.
4. On the Tamper Protection tab, uncheck Protect Symantec security software from being tampered with or shut down.
5. Click OK.
6. Close Symantec Endpoint Protection.

snapshot controlfile in Oracle RAC must be on shared location on versions >=11.2.0.2

source: 

https://dbatrain.wordpress.com/2011/09/

On a recent Oracle Certified Masters (OCM) prep workshop, a question arose concerning the purpose and use of the RMAN Snapshot control file. This in turn led to some interesting exploration of a change in Oracle 11g R2 beginning in 11.2.0.2.

To understand this change it is first a good idea to review the snapshot controlfile which in turn requires an understanding of RMANResync operations.

RMAN Resync Operations
RMAN performs Resync operations when the RMAN Client is connected to a target and an RMAN catalog. There are also two ways forResync to be invoked:

• Manual Resync – using the RESYNC CATALOG command;
  
• Automatic Resync – this may be partial or full as explained below.

There are two types of Resync:

• Full Resync
• Partial Resync

To understand when these are done, consider that the controlfile contains certain records that are able to be overwritten based on theCONTROLFILE_RECORD_KEEP_TIME parameter. These are records in the controlfile, that contain details of archivelogs produced and which may be overwritten once those details are copied to the catalogue. But many of the other controlfile record types are not overwritten as they represent persistent configuration details. These records include but are not restricted to things such as:

• Database Record
• Redo Thread Records
• Log File Records
• Checkpoint Progress Records
• Tablespace Records
• Filename Records
• RMAN Persistent Configuration Records

Details of all the record types, including the number of records per type is available in the V$CONTROLFILE_RECORD_SECTION view.

When changes occur only to the records that may be overwritten, then a Partial Resync is performed automatically the next time that theRMAN client connects to the target and the catalogue and does any of the following:

• Backup
• Restore
• Recover

A Full Resync occurs in the following cases:

• When changes occur to any non-overwriteable section of the controlfile and any of the three commands listed above is issued
• When a database is first registered in the catalogue using the REGISTER DATABASE command
• When a RESYNC command is issued from the RMAN Prompt

Snapshot Controlfile Locations

Prior to Oracle 11.2.0.2, The Snapshot Controlfile was used only during a Full Resync to reduce the duration of the CF ENQUEUE held exclusively on the controlfile. The enqueue prevents updates to any of the control file records, because there are dependencies between records in some sections and others. For example, there are tablespace records and file records, and during a Full Resync, the consistency between these two record types must be maintained until all the controlfile records are resync’ed to the catalogue. This prevents Oracle processes making changes to anything in the controlfile that might cause the records to become inconsistent.

But the controlfile is frequently updated in a busy system, so instead of holding the CF ENQUEUE for the duration of the resync, the controlfile is essentially copied to the “Snapshot” controlfile location in one go whilst holding the CF ENQUEUE, and then it is dequeued. The catalogue is then resync’ed from the “Snapshot”.

By default, the “Snapshot” is written to the $ORACLE_HOME/dbs directory which may be seen by doing an RMAN SHOW ALLcommand. But this may be configured to another location if required.

In RAC for example, the directory for the snapshots, must be a valid path name on any node in the cluster which has an instance of the database, to guarantee that the snapshot may be created regardless of which instance is serving the RMAN client. But here is where the change occurs.

Prior to 11.2.0.2, the Snapshot Controlfile location did NOT require shared storage, only that the path was valid from all nodes as stated above. From 11.2.0.2, it must be in shared storage when using RAC. If not then one might see the following:

RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03009: failure of Control File and SPFILE Autobackup command on 
ORA_DISK_1 channel at 31/08/2011 13:34:07
ORA-00245: control file backup operation failed

What is going on?  The answer is that the Snapshot Controlfile is being used for ordinary controlfile backups from 11.2.0.2 for:

• Control file backups taken manually from SQL*PLUS
• Control file auto backups taken by the Oracle server when configured from the RMAN client

For example here is what happens if a control file backup is attempted in RAC in 11.2.0.2 when not using shared storage:

SQL> alter database backup controlfile to ‘/u01/app/oracle/product/11.2.0.2/dbhome_i/dbs/ctlbackup.ctl’ ;
ERROR at line 1:
ORA-00245: control file backup operation failed

The $ORACLE_HOME/dbs directory is normally local in RAC, since the entire ORACLE_HOME is on local storage. This facilitates rolling patches, but from 11.2.0.2 the dbs directory is no longer useful for the snapshots.

The reason for this change is that control file backups traditionally used the CF ENQUEUE to lock the controlfile for the duration of the backup but in some high workload systems this was a performance bottleneck. The solution, was to take the controlfile backup from the snapshot and avoid holding the CF ENQUEUE whilst doing it. But that required maintaining the snapshot as changes occur to the controlfile. Since changes could occur from any instance of the database, the snapshot must be on shared storage, just like the proper control file is.

Look at the OERR output for the error:

> oerr ora 00245

00245, 00000, “control file backup failed; target is likely on a local file system”
// *Cause: Failed to create a control file backup because some process
// signaled an error during backup creation. This is likely caused
// by the backup target being on a local file system so it could not
// be accessed by other instances. It can also be caused by other
// I/O errors to the backup target. Any process of any instance that
// starts a read/write control file transaction must have access
// to the backup control file during backup creation.
// *Action: Check alert files of all instances for further information.

When upgrading to 11.2.0.2 under RAC, make sure to avoid this problem by using RMAN to configure the Snapshot Controlfile to a shared location:

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/snapcf_?.f';

dump_table_to_csv procedure

 exec DUMP_TABLE_TO_CSV('ULS.MARKET','DATA_PUMP_DIR','market.csv');


CREATE OR REPLACE procedure SYS.DUMP_TABLE_TO_CSV( p_tname in varchar2,
                                                   p_dir   in varchar2,
                                                  p_filename in varchar2 )
   is
        l_output        utl_file.file_type;
        l_theCursor     integer default dbms_sql.open_cursor;
        l_columnValue   varchar2(4000);
        l_status        integer;
        l_query         varchar2(1000)
                       default 'select * from ' || p_tname;
       l_colCnt        number := 0;
       l_separator     varchar2(1);
       l_descTbl       dbms_sql.desc_tab;
   begin
       l_output := utl_file.fopen( p_dir, p_filename, 'w' );
       execute immediate 'alter session set nls_date_format=''dd-mon-yyyy hh24:mi:ss''
';
  
       dbms_sql.parse(  l_theCursor,  l_query, dbms_sql.native );
       dbms_sql.describe_columns( l_theCursor, l_colCnt, l_descTbl );
 
       for i in 1 .. l_colCnt loop
           utl_file.put( l_output, l_separator || '"' || l_descTbl(i).col_name || '"'
);
           dbms_sql.define_column( l_theCursor, i, l_columnValue, 4000 );
           l_separator := ',';
       end loop;
       utl_file.new_line( l_output );
  
       l_status := dbms_sql.execute(l_theCursor);
  
       while ( dbms_sql.fetch_rows(l_theCursor) > 0 ) loop
           l_separator := '';
           for i in 1 .. l_colCnt loop
               dbms_sql.column_value( l_theCursor, i, l_columnValue );
               utl_file.put( l_output, l_separator || l_columnValue );
               l_separator := ',';
           end loop;
           utl_file.new_line( l_output );
       end loop;
       dbms_sql.close_cursor(l_theCursor);
       utl_file.fclose( l_output );
  
       execute immediate 'alter session set nls_date_format=''dd-MON-yy'' ';
   exception
       when others then
           execute immediate 'alter session set nls_date_format=''dd-MON-yy'' ';
           raise;
   end;
/

sybase logon trigger to prevent unauthorized user connections

USE sybsystemprocs
go
IF OBJECT_ID('dbo.sp_login_trigger') IS NOT NULL
BEGIN
    DROP PROCEDURE dbo.sp_login_trigger
    IF OBJECT_ID('dbo.sp_login_trigger') IS NOT NULL
        PRINT '<<< FAILED DROPPING PROCEDURE dbo.sp_login_trigger >>>'
    ELSE
        PRINT '<<< DROPPED PROCEDURE dbo.sp_login_trigger >>>'
END
go
create procedure dbo.sp_login_trigger
as
declare
        @loginname varchar(32),
        @hostname varchar(32),
        @ipaddress varchar(32)


--This is an example to simply restrict user bsun from connecting to the server via a specific IP address
--To configure a login-specific login trigger:
--sp_modifylogin my_login, 'login script',sp_login_trigger
--To drop the login trigger
--sp_modifylogin my_login, 'login script',NULL

-- drop the global login trigger
--sp_logintrigger 'drop'

-- change the global login trigger
--sp_logintrigger 'your_db.dbo.a_different_proc'

--To change the login trigger
--sp_modifylogin my_login,'login script',a_dirrerent_sp
--TO CONFIGURE a GLOBAL LOGIN TRIGGER
--sp_logintrigger 'sybsystemprocs.dbo.sp_login_trigger'
--or: sp_modifylogin NMULL,'login script','sybsystemprocs.dbo.sp_login_trigger'


select @loginname=suser_name(suid), @hostname=rtrim(clienthostname), @ipaddress=rtrim(ipaddr)
from master.dbo.sysprocesses where suid=suser_id()
--print "BEFORE IF"
--print @hostname
print @loginname
print @ipaddress

--if (@hostname='P019323' and @loginname='bsun') or (@ipaddress='192.168.23.74' and @loginname='bsun')
if @ipaddress='165.135.23.74' and @loginname='bsun'

    begin
        print 'Restricted User %1! using %2! blocked out', @loginname, @hostname
        print 'User %1! is not allowed to connect to %2! from %3!', @loginname,@@servername,@ipaddress
            /* Log an entry in an audit table */
            --insert into APP_ACCESS_VIOLATION values (@loginname, @appname, getdate(), 'Access Violation')
        select syb_quit()
    end
go
EXEC sp_procxmode 'dbo.sp_login_trigger', 'unchained'
go
IF OBJECT_ID('dbo.sp_login_trigger') IS NOT NULL
    PRINT '<<< CREATED PROCEDURE dbo.sp_login_trigger >>>'
ELSE
    PRINT '<<< FAILED CREATING PROCEDURE dbo.sp_login_trigger >>>'
go
REVOKE EXECUTE ON dbo.sp_login_trigger FROM public
go
GRANT EXECUTE ON dbo.sp_login_trigger TO public
go

dba_2pc_pending distributed transaction cleanup delete

Hi,

You Can try the following to rollback your transactions:
(It appears that you are seeing distributed transactions as Prepared instead of collecting.

Try running this:

SQL> select LOCAL_TRAN_ID,STATE from DBA_2PC_PENDING;


Then based on your results issue the following:

SQL> rollback force '';


SQL> commit;

SQL> alter system set "_smu_debug_mode" = 4;

SQL> exec dbms_transaction.purge_lost_db_entry('');

SQL> exit


You should repeat this for each entry that you get back from the first query.

Good luck.

Stacy

sybase interface file convert from TLI to TCP

SERVERNAME

      master tli tcp /dev/tcp \x000213880a8d6b360000000000000000

      query tli tcp /dev/tcp \x000213880a8d6b360000000000000000

Indicates that this is a "tli address" family. This is always the start of the start of a TLI address. TCP/IP is family 2, depending on network vendor and byte order of the machine, the most common is 0002, or 0200 depending whether the machine is 'big endian' or 'little endian'. Check your current interfaces file.	This is the hexadecimal equivalent of the port number	This is the first part of the IP address.	This is the second part of the IP address.	This is the third part of the IP address.	This is the fourth part of the IP address.	This is a 'padding' value, and is platform dependant, on Solaris it is 16 zeros. It is mandatory
\x0002	1388	0a	14	1e	28	0000000000000000

Resetting forgotten Oracle Linux root password

http://frogtec.blogspot.com/2009/04/oracle-enterprise-linux-forgot-root.html